Easy No , Hard No

When you ask manager to list what are the most difficult things to do?
You will find one answer in top of the list mostly "Saying no"

Here,I would like to explain you Easy no and hard no and how to deal with them.

If your employee come and ask you some thing to finish as per your earlier discussion with him/her.
You will check feasibility and if its not feasible you will say "no, we will do it later on".

This is an easy no.
(a) you have strong logic behind your decision,
(b) Person who is asking is with lower power and authority
Suppose you dont have above two and you require to take decision at that time ,it will be Hard no.

You will find difficulty to get the way of saying hard no.Manager often face this situation.

I read article in Tech republic and found few helpful things.

Know the facts. More you know about the issue , more you will be able to identify problem, solution and more you will be able to defend you decision.

Believe in yourself. If you will doubt yourself then you will find difficulty to win over others.

Don’t take it personally. Always Remain emotionally detached while dealing with this kind of issue.
Understand your position relative to others. Realize that saying no is a statement of position and the weight of your no is dependent on your relative position of authority/power and your persuasiveness.

what is procrastination?

Does your to do list increase day by day?Are you adding same task again & again because of UN finished or not yet started status?

That means deferment of actions or tasks to a later time which increase your anxiety,This is by all means Procrastination. It is now common in IT industry as of being over loaded by tons of work to do.

People who are sick with procrastination work same amount of time as common people do but as they are not capable of putting right thing in right basket they usually busy with undeserving tasks.

They do not have any priority table or do not understand work break up structure perfectly. Usually they are not able to interpret meaning of Urgent Task and Important tasks.

There are more then on reason for procrastination such as chunking, inability to organize things, forgetfulness.

Procrastination is had major drawback on psychological manner too…it used to indulge feeling of guild, self-disgust & depression.So, it requires to be cured promptly as it is identified.

I hope this will help you to identify what is Procrastination; I will help you to get rid of it in my next article.

Time estimation of project

Hi use following technique for time estimation of project.
P.E.R.T
Programm evaluation and review technique.
It averages Pessmistic estimation,Most Likely and Optimistic.
A.E.T.=Aprox.Estimated time
P.E.=Pessimistic Estimation
M.L.E.=Most likely Estimation
O.E.=Optimistic Estimatoin

A.E.T.=(P.E+4(MLE)+O.E)/6.

Assess Yourself for better progress

I understand the mission/vision of my organization. Yes or NoPlease explain answer.........

2. I know what I am accountable for. Yes or No
Please explain answer........

3. I know how to measure my progress. Yes or NoPlease explain answer.......

4. I have the tools, knowledge and support I need to do my job well. Yes or No
Please explain answer.......

5. At work I have the opportunity to succeed daily. Yes or No
Please explain answer.......

6. I receive regular constructive communication from my supervisor. Yes or No
Please explain answer.......

7. I feel my supervisor cares about me as a person, not just as an employee. Yes or No
Please explain answer.......

8. I am encouraged to continually develop my skills. Yes or No
Please explain answer......

9. My opinions are valued by my supervisor. Yes or No.
Please explain answer.......

10. I would encourage anyone who is qualified to work for my organizationand for my supervisor. Yes or No
Please explain answer......

Try to give answers of these questions and assess Your self.....

I got this tutorial from leadershiptools.com

Few Quotes to build up spirit.

"Mistakes are the portals of discovery."
- James Joyce

"Results? Why man, I have gotten a lot of results. I know 50,000 things that won't work."
- Thomas A. Edison

"There is no security on this earth: There is only opportunity."
- General Douglas MacArthur

"The trouble with most of us is that we would rather be ruined by praise than saved by criticism."- -Norman Vincent Peale

"Assume nothing, pursue everything."
- Kevin Riper

"The best preparation for tomorrow is to do today's work superbly well."
-Sir William Osler

"To find fault is easy: To do better may be difficult."
- Plutarch

”Coming together is a beginning.
Keeping together is progress.
Working together is success.”
- Henry Ford

”The ratio of We’s to I’s is the best indicator of the development of a team.”
- Lewis B. Ergen

”I am easily satisfied with the very best.”
- Winston Churchill

”The future belongs to those who see possibilities before they become obvious.”
- John Scully

”A championship team is a team of champions.”
- Unknown

Things a developer should never ignore

1: Clarifying user requirements

As you spend more time developing an application, you can sometimes predict some of the requests of your customers. Don’t take this for granted and assume you know more than your users do. When you receive the requirements, spend some time with them and review their specification to confirm you are on the same page. Not doing so can end up costing you time as you rework the application later on.

2: Collaborating

Call it brainstorming, call it peer code review, call it whatever you want — but just make sure you collaborate with those around you. Bouncing ideas off others will help you identify any holes in your potential solution and might even help you develop a solution better than your original design.

3: Version control

Anybody who has ever had his or her code stepped on or deleted knows the value of a good version control system. It doesn’t matter if its CVS, ClearCase, or even Visual Source Safe. Get it, learn it, and use it. You don’t want all your hard work to be blown away with a few mistaken keystrokes.

4: Basic system testing

Most developers don’t like to test. Or maybe I should say most developers hate testing. But it’s crucial for you to do your own testing before you release it to anybody else. Nothing will get your testing group upset and knocking on your door quicker than receiving code that doesn’t perform the basics. Make sure entry screens allow input, check that you can’t enter a letter where only numbers are allowed, verify that reports actually print information and that columns add up — the basic stuff.

5: Usability

Early in my career, I designed a screen for a group of data entry users. I thought my design was so slick. The system had all the bells and whistles they needed and then some. I was just about ready to install it when it was pointed out to me that the users almost never used a mouse. My design had added some buttons to the screen and had them lifting their hands from the keyboard over and over. Not efficient for them and very humbling for me. Spend some time to learn about the types of usability issues your customers may have and everybody will be happier.

6: System performance

In this era of instant gratification, it’s hard to satisfy end users. When they click on a button, they expect that the system will immediately respond. Or they may have the misconception that overnight processes really should take only an hour or two. When developing your application, ensure that you understand what type of response the users expect and require.

7: Comments in your code

Comments are the bane of many developers’ existence. We want to spend our time writing code not writing about code. But most of us have been tasked at some point with going in and maintaining somebody else’s work. If you’re like me, you may have sometimes found it so confusing that your first reaction was to rip it all out and start over. My experiences have taught me that even by adding some very basic commenting around sections of code and trying to use descriptive variable names and the like, you can have a significant positive impact on the next person who has to maintain your legacy.

8: Logging

When you’re developing applications (especially those without any type of user interface), make sure you build some helpful logging solutions into the code. There are few worse things for a developer to do than to try to debug an application with little visibility into what is going on when it is running.

It doesn’t have to be overly complex. Maybe just writing out some of the values of your variables or counters at certain places in the code or when it hits certain subroutines. You can set it up so it logs only when a particular environmental condition exists (maybe a specific text file exists in a directory). Trapping anything that is going to help you track down and resolve issues quickly is what you’re going for here.

9: Keeping your skills up to date

Still coding in something a few years old? Many people work for companies run by legacy applications that are past their prime. But that doesn’t mean you should ignore what’s going on in the world around you. A lot of the new technologies out there can be integrated and could provide a boost to you and your company. Take some time to try to understand them a bit, and who knows when you can use it to your advantage.

10: Taking pride in your work

One thing I always thought about and tried to pass along to my teams was the concept of having pride and ownership in the applications we were responsible for. I never wanted to hear that my applications weren’t working at their peak capabilities or that users were happy. And if we did hear about a problem, we would go out of our way to do everything we could to rectify the situation immediately.

It doesn’t matter if you are a head-down developer in a large organization, a systems designer, or a single jack-of-all-trades for your own company. Taking some of these ideas into consideration will not only help you produce a better end product but it will also allow you continue to evolve yourself and your career to the next level.

Source :Techrepublic Blogs and articles

Few things to motivate your team.

#1: Believe in your team’s objectives
Do you believe in what you want the team to accomplish? Do you think your goals are realistic? If not, rethink your position, because your team will sense your uncertainty. You may say the right words, but your body language and overall demeanor will give you away. On the other hand, if you truly are dedicated and believe in your goals, your team will sense it and will react accordingly.
#2: Model the behavior you want from the team
Don’t be a hypocrite — lead by example. You want your team to interact courteously and professionally with others, but do you do so yourself? If you ask them to put in extra hours, are you there along with them? Country artist Rodney Atkins sings about how one day, his four-year-old son said “a four-letter word,” but how later that night, all by himself he got on his knees and prayed. What did the son say when asked about how he learned to do both things? “I’ve been watchin’ you.”
#3: Keep a positive attitude
Game 1 of the NBA Finals has just begun. Fifteen seconds into the game, one team connects on a field goal, making the score 2-0. The other coach slumps in his chair, puts his head in his hands, and yells, “@(*@&@, this series is OVER!!”
(On November 12, 1989): Person 1: “The Berlin Wall just came down!” Person 2: “Horrible! The guards are now out of a job!”
Don’t laugh. If you have these attitudes, how do you think your team will react? If you model a negative attitude, your team will pick it up. I know it sounds trite, but try to stay upbeat.
Doing so doesn’t mean being unrealistic. It does mean, however, that you try to look at the glass as being half full rather than half empty. Instead of saying, for example, “This project will never succeed because of issues 1, 2, and 3,” consider saying, “If we want this project to succeed, it’s critical that we resolve issues 1, 2, and 3.”
#4: Be clear about your goals
It’s hard for your team to accomplish its goals if those goals are unclear or unknown to them. More important, it’s hard to get them even to agree with those goals if they don’t know what they are. Make sure your team knows what you are expecting of them. If you can quantify your goals so that you can measure how well you did compared to what you expected, so much the better.
#5: Get feedback from the team members
Unless you hear from your team members, you may have little or no idea of how effective or clear you are. Few of us enjoy hearing bad news or criticism, but if there’s a problem in what we’re doing, it’s important that we hear it.
When discussing issues with the team, don’t shoot the messenger. When listening to a team member, try to separate the message and issue from the person. Similarly, when someone is offering suggestions or discussing issues, try to separate your own self and ego from the discussion. If you do shoot the messenger, all you will have done is make your team even more reluctant to talk frankly with you in the future.
#6: Set expectations
Make sure your team knows what to expect of you. If they do, there’s less chance that they’ll be unpleasantly surprised or disappointed.
Suppose, from the previous point, you had a discussion with a team member, who made a few suggestions. Some of them are workable (so that you could act on them), but others aren’t. Before having this discussion, it would be good to let your team know that while you will listen to them, you may or may not adopt all of their suggestions. One would hope they’d realize this already, but it’s best to be explicit. Furthermore, if you do adopt a suggestion, make sure everyone knows about it.
#7: Avoid mixed messages
Consultant and trainer Robert Mager, in his book Analyzing Performance Problems, discusses the uses of consequences and rewards in shaping human behavior. Specifically, he points out that to encourage desirable behavior, there must be positive rewards for it. Conversely, to discourage undesirable behavior, there must be consequences that result from it. Believe it or not, some people mix up these two points. Have you, as a parent, ever said to your child, “Any time you have problem, you can talk to Mommy or Daddy”? What happens when they do? You become irritated and yell at them, “Come back later! Can’t you see I’m busy?!” If you send similar mixed messages to your staff, you will make it harder for them to act the way you want.
#8: Know the difference between exhorting and belittling
It’s fine and good for you to want greater and higher quality results from your team. However, be aware of the line between exhorting someone to do better and belittling them because they aren’t right now. The latter might work, but the chances are greater that it might only create resentment and turn out to be counterproductive.
A couple of weeks ago, after a rehearsal of the choir I direct, I said to two young men, “I want to see confidence in your eyes when you’re singing.” I didn’t say to them, “You idiots, you don’t know the music.” In other words, in keeping with the positive/negative point discussed earlier, I focused on where I wanted them to be, rather than on the fact that they weren’t there right now.
#9: Correct in private
If personal issues of a team member are becoming a problem, address them with the person in private. Don’t embarrass the person by bringing it up in public. Such issues include attendance and punctuality, dress, and general professionalism.
What about a mistake involving work? Use discretion here. Using the choir example again: Suppose a person has an incorrect rhythm in a measure. I will just take a moment and work it out with that person in front of the group. If he or she gets it, fine. However, if he or she were consistently missing notes and rhythms, I would need to talk privately with that person to see what’s going on.
#10: Praise in public
When someone does something right, you probably are happy and want that person to continue doing it. You also probably want to make that person look good in front of the others, and for the others to be motivated to improve their own performance. For those reasons, recognize good work in public, rather than in private.
Other things being equal, of course, most people would prefer money and praise rather than praise alone. However, praise alone still can motivate, as long as you’re sincere and specific in what you’re praising. Generalities are unhelpful. Rather, focus on the specific action, and how it benefited the group.
In the case of the young men I mentioned earlier, I spoke to them again just a few days ago, after our last rehearsal, which went really well. I said to one of them, “Remember I told you I wanted to see confidence in your eyes? Well, I see it now.” To the other, I said, “You’ve been practicing, right?” When he nodded yes, I continued, “See what a difference it makes?”
#11: Believe in your team
England expects every man to do his duty.
The Battle of Trafalgar, in 1805, established British naval supremacy for decades afterward. In that battle, a fleet led by Admiral Lord Horatio Nelson defeated a combined French and Spanish fleet off the coast of southwest Spain, near Cape Trafalgar. As both sides were preparing for the battle, Nelson sent his now-famous message to his fleet. Sadly, Nelson suffered a mortal wound and did not live to see his ultimate victory.
People tend to live up, or down, to your expectations. If you expect high performance from them, and they realize it, you have a greater chance of getting such performance than if you expect low performance.
It can be rewarding to see a team come together and execute the way you want. It’s even more rewarding to see people develop the way you want. However, try to be realistic. The members of my choir are all teenagers and friends with my younger daughter, Rayna. One day, I asked her, “Rayna, do some people in the choir tell you how much I’ve influenced them?” At that, Rayna replied, “Daddy, don’t flatter yourself.”

Note:Source Techrepublic

What is CMM level

A maturity model is a structured collection of elements that describe certain aspects of maturity in an organization. A maturity model may provide, for example:

• a place to start
• the benefit of a community’s prior experiences
• a common language and a shared vision
• a framework for prioritizing actions
• a way to define what improvement means for your organization.

A maturity model can be used as a benchmark for comparison and as an aid to understanding - for example, for comparative assessment of different organizations where there is something in common that can be used as a basis for comparison. In the case of the CMM, for example, the basis for comparison would be the organisations' software development processes.

The levels are:

Level 1 - Ad hoc (Chaotic)

It is characteristic of processes at this level that they are (typically) undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events.

Level 2 - Repeatable

It is characteristic of processes at this level that some processes are repeatable, possibly with consistent results. The processes may not repeat for all the projects in the organization. The organization may use some basic project management to track cost and schedule.

Level 3 - Defined

It is characteristic of processes at this level that there are sets of defined and documented standard processes established and subject to some degree of improvement over time. These standard processes are in place (i.e., they are the AS-IS processes) and used to establish consistency of process performance across the organization. Projects establish their defined processes by applying the organization’s set of standard processes, tailored, if necessary, within similarly standardized guidelines.

Level 4 - Managed

It is characteristic of processes at this level that, using process metrics, management can effectively control the AS-IS process (e.g., for software development ). In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Process Capability is established from this level.

Level 5 - Optimized

It is characteristic of processes at this level that the focus is on continually improving process performance through both incremental and innovative technological changes/improvements.

The CMMI contains several key process areas indicating the aspects of product development that are to be covered by company processes.

Key Process Areas of the Capability Maturity Model Integration (CMMI)

Abbreviation	Name	Area	Maturity Level
REQM	Requirements Management	Engineering	2
PMC	Project Monitoring and Control	Project Management	2
PP	Project Planning	Project Management	2
SAM	Supplier Agreement Management	Project Management	2
CM	Configuration Management	Support	2
MA	Measurement and Analysis	Support	2
PPQA	Process and Product Quality Assurance	Support	2
PI	Product Integration	Engineering	3
RD	Requirements Development	Engineering	3
TS	Technical Solution	Engineering	3
VAL	Validation	Engineering	3
VER	Verification	Engineering	3
OPD	Organizational Process Definition	Process Management	3
OPF	Organizational Process Focus	Process Management	3
OT	Organizational Training	Process Management	3
IPM	Integrated Project Management	Project Management	3
ISM	Integrated Supplier Management	Project Management	3
IT	Integrated Teaming	Project Management	3
RSKM	Risk Management	Project Management	3
DAR	Decision Analysis and Resolution	Support	3
OEI	Organizational Environment for Integration	Support	3
OPP	Organizational Process Performance	Process Management	4
QPM	Quantitative Project Management	Project Management	4
OID	Organizational Innovation and Deployment	Process Management	5
CAR	Causal Analysis and Resolution	Support	5

Source:WikiPedia

We have two ears and one tongue

Here i want to tell you few of required attribute of prolific leader
Person must have a great listening ability.
Good leader does not listen from eyes only but they are used to trace physical mental signal passed by team members.

so for being good leader listening skill is as important as speaking.

I am just recently appointed to handle more people now i am more conscious about my listening ability.

So start listening.

Thanks
Ketan

Documentation Realy Requires?

As far as software industry concern ,Documents are really required thing.

software engineers for small and medium scale organization are not aware of the actual benefit of documentation at all.
They are used to ignore or avoid documentation as much as they can due to uneven project sch dueling and high work load.
But as my experience grows in this industry.I really admit one should prepare as many document as he/she when ever get 2 or 3minutes.
Maintain each Change Request,Task Estimation sheet.Database changes as much as you can.

Sooner or later this will help you for sure. Learn more about Microsoft excel it is a great tool for managing information. and Microsoft Project this is also one of more recognized project management tool.

Thanks
Ketan

Avoid Conflicts

For a good carrier this thing should be must. whenever you are not agree with your senior person do not be in hurry to refuse.
Each person have their own ego we can not ignore it at all.so you can just give your doubts to him/her and ask opinion rather giving suggestion.
(personally i learn this tactics by my own personal experience ).
Keeping cool head with a hot ideas are the key to success in any industry.
always keep your logic moving but make your head still.

Be acceptable be adaptable

From my experience in software industry. (Yes not too much experience where i can come in to any solid conclusion).

I found few things which are keys to success.

• Accept one thing that nobody knows everything.

if you fail to get any solution please do not try to spend more time to search them in to search engines.Yes off course if problem is little then you must go to search engine. but whenever you stuck and do not have solution ,do feel shy to ask you mates.

Please just rush to them and give your problem and get their views this will save tremendous time. and also you will have number views about your problem.

In early days ,in fact currently i sometime waste time to search all things on my hand ..but whenever above thought came into my mind i just ask my mates and ask them about my solution.
first benefit is that you will know you mates and his perception. and will restrain you to be a introvert.

• Second most required quality i found is adaptability.

Here i do not meant to say developer should me adaptable for all kind of platforms like .net dev. should adapt java's module.
I am putting focus here about projects and number project switching during you job,
develop high adaptability whenever you are assigned for any project (New or Existing ),You must be able to adapt it very soon.
This will stamp your efficiency to your seniors, because seniors have their own responsibility they are having more time shortage then us.
so seniors always looking for a person who can handle project or task by their own with lesser number of queries.they never wanted to spend time in a explaining in detail about requirement specification.And that is acceptable.

so highly adaptable person have more chances of promotion.

• Third- Please be acceptable

If any from your organization have problem and they think whether i should ask [you] or not.
this is a warning signal.
Please always be helpful. As you give your 5 min to somebody for helping them(Yes manage your tasks too).you are earning 5 min from everybody from people you nearby.


have gr8 carrier.

How to gether requirement specification

Hi, this post is about people who are new in leadership . and they learning phase for client communication.

Please visit techrepublic site every day and enrich your ability There are many ways to gather requirements. Interviewing–where you talk to the people who will define the new solution to determine what they need– is probably the default technique for most projects.
Interviewing can be an easy process if the person you’re talking to is organized and logical in their thought process. Since that’s not always the case, however, you have to have employed good interviewing techniques in order to start and guide the interview.
There are a number of formal interviewing techniques that will make the requirements gathering process go more smoothly. Here they are.Start off with general questions. Typically, you don’t start the discussion by asking narrow, targeted questions. You’ll want to start more high-level and general questions. These questions should be open-ended, in that they require the interviewee to explain or describe something and can’t be answered with a “yes” or a “no.” Your goal is to gather as much information as possible with the fewest number of questions.

· Ask probing questions. After you ask general, open-ended questions, you should then start to probe for details. Probing questions are probably the most valuable type of questions, since they tend to result in the detailed requirement statements you’re looking for.

· Be persistent. If you experience any difficulty understanding the interviewee’s point, ask follow-up questions. You can also ask for examples that will illustrate the points the interviewee is making.

· Ask direction questions when you need additional information. Direction questions start to take the discussion in a certain direction. They’re used to provide context and background. For example, “Why is that important to you?” or “Why do you care about that?” are questions that can provide direction.

· Ask indirect questions to gain better understanding. Indirect questions are used to follow up on specific points that were raised previously. These questions are used to gain more clarity so that you can ask better questions next. For example, “Is that important because of …” or “You said everything needs to be secure because…”

· Ask questions that validate your understanding. A good interviewing technique is to restate what you just heard back to the interviewee to validate that you understood him/her correctly. For example, after hearing an answer, you could say “If I understand you correctly …”

· Paraphrase. This is similar to the prior technique except that you would take a large amount of information from the receiver and simplify it in your own words. For instance, after hearing the interviewee give a five-minute answer on how a process works today, you could paraphrase the basic points of what he/she said in a quick bulleted list of process steps. For example, “So, in other words, the process you use today is basically 1, 2, 3, 4…”

· Ask for examples. In many (or most) cases of gathering requirements, the interviewer is not totally familiar with all of the information provided by the interviewee. Therefore, one effective way to gain more understanding is to ask for examples. This can also be utilized when the interviewee provides feedback that does not sound totally valid or totally believable. Asking the interviewee for an example helps lend a concrete and specific instance that may help make the requirements clearer. For example, “Can you give me an example of how that affects you?” can help make a statement more clear.

· Keep the discussion back on track. Sometimes the interviewee starts to talk about things that are outside the scope of the specific information you’re trying to gather. This is sometimes caused by a misunderstanding of the question you asked. Other times it’s caused by a lack of focus or a desire to talk about things that are of more interest to the interviewee. When the discussion gets off track, the interviewer must get back on track. An example of this technique would be “That’s a good point. However, can you describe how that relates to (… restate your original question…)?”

· Try to stimulate ideas. Sometimes the interviewee gives the obvious answers but isn’t thinking about other areas that may not be as obvious. The interviewer should try to get the interviewee to stretch a little and think about things that are not quite as obvious. For instance, you can ask “Can you think of a couple options for this situation?” or “Are there other ways to solve this?”

Preface

Hi,

I am starting new blog for IT leadership and some more tactics about Working in IT organization.

Most probably I will write some of articles which i get from another good sites. and some of my experience,along with my Thoughts :).

As usual after being a computer engineer .. I am always wondering are we really helping our country to reduce poverty ?

Anyway this is not the best questing to begin with.

Hope you will like my postings....