How to set up KRA’s/KPI’s (Performance Management using KRA’s)

“Performance Management using KRA’s” has been one of the top posts on this blog. Well defined KRA’s act as a scale to measure performance of a team member.

Here is an excerpt from my earlier post:

Documented result areas provided us a path to tread. We knew what exactly is expected out of us and we performed accordingly. KRA’s deal with results and not with day to day activities and hence more quantitative the KRA’s are the easier they are to track.

In this regards, one of the readers of this blog, Gireesh Sharma pointed me to his article “Writing SMART Goals (also called KRAs) from Job Descriptions” which made for an interesting read.

Here are 9 steps suggested by Gireesh for setting up KRA’s/KPI’s:

1. Go through employee’s Job Description. If Job Description is not updated talk to employee and his/her Manager or many be manager’s manager also.
2. Try to find out exactly what the employee is supposed to achieve.
3. Based on your reading and discussions, make a list of the functions and responsibilities which are critical to the employee’s job.
4. Categorize these critical functions and responsibilities in two categories:
   1. (4.1) Which can be measured whether in numbers or percentages or yes/no.
   2. (4.2) Which cannot be measured in numbers and cannot be calculated.
5. Ones in 4.1 are the can be be converted to Goals (KRAs).
6. Make a list of all critical functions.
7. Write a self explanatory (1 sentence ) definition of each Goal (KRA).
8. If you plan to follow BSC (Balanced Score Card) Pattern, then categorize each goal into one of the following categories: Customer, Financial, Internal Business Process, Learning and Growth.
9. There after describe each Goal (KRA). Make sure you mention a measurable target to be achieved and time frame for achievement of the Goal (KRA).

The article is very insightful and has very relevant examples to demonstrate how this 9 point process works. Read the full post here.

How do you manage results from your team?

Leadership Development Carnival – April Edition

The April Leadership Development Carnival is up at “Great Leadership” blog by Dan McCarthy. For those who are aren’t aware of Carnival concept, Carnival is a blog event where excellent insights on a particular topic are hosted in form of single post with links to original blog posts.

“Great Leadership” is an excellent Leadership blog which offers remarkable insights on Leadership and related subjects and is also the host of Leadership Development Carnival.

I am happy and proud that one of my posts “Personal Leadership – It shines in difficult times” has been included in the Leadership Development Carnival along with other great blog posts on Leadership subject. I am particularly excited because this was my maiden participation in a blog carnival.

Recognition is important because it pushes you to do better – and inclusion of my post on Leadership Development Carnival just does that!

I recommend you to drop by the Leadership Development Carnival to read some very useful and practical insights on Leadership.

Thoughts on Change Management

Being into process management, and often responsible for implementing change, I can vouch for the fact that implementing change is difficult. While some change management initiatives succeed, most of them fail – because people often see change as a threat which will pull them out of their comfort zone and make them vulnerable. Yet, change is inevitable.

Some ideas on change management, via Harvard Business Review’s brief on “Change through Persuasion” –

“Conduct a four-stage persuasion campaign:

1) Prepare your organization’s cultural “soil” months before setting your turnaround plan in concrete—by convincing employees that your company can survive only through radical change.

 2) Present your plan—explaining in detail its purpose and expected impact.

3) After executing the plan, manage employees’ emotions by acknowledging the pain of change—while keeping people focused on the hard work ahead.

4) As the turnaround starts generating results, reinforce desired behavioral changes to prevent backsliding.”

Change management has to be done painstakingly – and with a little more care and persuasion, the resistance to change can be controlled.

As Mike Kanazawa says “People Don’t Hate Change, They Hate How You’re Trying to Change Them.”

(Thanks to Rajesh Shetty for pointing to Mike’s ChangeThis Manifesto).

Requirements Management Practices and Project Management

One of the biggest culprit in software project failure is poor requirements management and that implies that project manager must should be well versed with requirements management practices while also being open, responsive and adaptable to the changes in requirements according to the changing business needs of the client.

I have worked with projects where the requirements are very clear and have also worked on ones where requirements/product features came in evolutionary model. Specifically in offshore model, it is important to get a clear signoff on each requirement from the client – easier said than done, but project managers have to constantly work at it. When it is difficult to gather set of requirements upfront, simple things like user stories, high level use cases or even simple understanding documents to write what we understand is enough to manage scope and get a signoff.

Gantthead has a nice article on “Requirements practices every project manager must know“. The article also lists benefits of having sound requirements management practices for best outcomes.

“Researchers have documented that 30 to 50 percent of total development cost can be attributed to rework…and requirements deficiencies account for more than 70 percent of that cost! “

How sound are your requirements management practices?

Software Testing – Cost or Investment?

There is an interesting thread going on over at LinkedIn Answers where Venkat asks whether testing is a cost or an investment.

Some of the key thoughts that crossed me when I read the trail are:

1. Be it a product or a services setting, software testing is an integral part of the development lifecycle. I would also go ahead and state that in cases (specially in services industry) where client does not pay explicitly for testing, testing should be treated as an internal investment that will help organization satisfy and in some cases, retain clients. Testing is directly related to an organizations reputation (quality of delivery).
2. So, software testing is an important investment from organization’s perspective. For clients, it is a cost that should be budgeted when a project is planned.
3. From Cost of Quality perspective, software testing is an appraisal cost which cannot be completely done away with. It can however be controlled by having good resources on project and making them accountable for unit level checks and basic integration testing. It also calls for streamlined requirements management and design practices.
4. That brings me to another realization that the outcome of a tester depends on quality of developers/designers on the project. I have seen very good testers failing to perform if the development team is average. On the other hand, average testers have performed well on projects where the team was more mature and accountable for unit level checks.
5. Lastly, defect trends should be closely monitored to improve upon the process – also to raise timely escalations on quality (raising alarm bells) so that client’s expectations can be managed early in the lifecycle.

These are some immediate thoughts to jot down – any thoughts to take this further ?

I would love to hear. Thanks again Venkat, for raising this all important question.

Lessons in project quality

We all know that Quality on a project is everybody’s business and right processes have to exist to ensure that everyone thinks about quality – be it review mechanism or having a set of metrics. Around the same time that I was thinking of documenting my learnings on this topic, I came across an article “Quality Doesn’t Just Happen“over at CIO.com which also documents lessons on project quality (included below are the ones which resonate well with my own learnings) :

“Lesson #1: Don’t reward for shipping on schedule. Anyone can ship garbage. Base rewards on quality metrics

Lesson #2: Don’t reward heroes for their Herculean effort late in the project to fix problems that could have—and should have—been fixed by the same people much earlier in the lifecycle.

Lesson #5: It’s easy to ignore documents that are sent by e-mail for approval. No response does not equal approval: No response means, “I didn’t have time to read it.”

Lesson #6: Don’t start coding until the requirements are stable and understood, or else budget time for subsequent rework.

Lesson #7: Code isn’t “complete” until it works. Good unit testing is part of the development effort, not an optional item to be jettisoned when the schedule is tight.

Lesson #10: Buggy software takes longer to ship. “

Any additions that you can suggest to the list above? Help me while I think of a few more!

On Code Commenting!

Commenting of source code is one of the most ignored software development activity. Although a very important part of coding process, developers often think they can do away without writing comments.

Missing code comments is one of the common findings of code review sessions being done across organizations.

I have seen people who write:

1. Useless comments e.g. For a function named InsertData(), the comment written is “This function inserts data into the database” when the function name explains the same!
2. Redundant comments like name of the class file, date created, date modified, modification details etc. – something that version control tool can do with much ease. The worst part is that once written, these comments are almost never updated!
3. Lenghthy comments which has more number of lines than the function being commented. Each and every instruction/code line is meticulously explained. This again becomes worse when descriptions are not updated.

So how much commenting is good? While there is no quantification of how much is good, only I can say is that the code comments should be reasonable and updated. Anything that genuinely describes something that is otherwise non-decipherable (like critical database transactions, complex algorithms etc.) is a good comment.

I have heard some programmers stating that if they focus on commenting, they loose the flow of coding and thought process. I suggest that developers can complete a functional class and take up commenting as a separate task (soon after the completion till the implementation details are fresh in mind).

Commenting may take up some time – but not as much as you/client might have to spend understanding a piece of code few months down the line!

Also Read:

1. Comments on Comments on Comments at Developer Magazine
2. In Praise of the Lowly Comment at Developer Magazine

Agile and Offshore

Agile is everywhere these days – my quest was to find out implications of using agile development methodologies in offshore model.  Agile in offshore model has been a topic of debate primarily since offshore and distributed development does not foster face-to-face human communication during the project lifecycle.

My quest lead me to read some interesting viewpoints on this topic. I admired the lessons Martin Fowler has shared in his article. From what I read, one thing was clear – it is too early to conclude upon the benefits of agile in offshore model. Offshore and agile may or may not go together.

As Martin says:

“We may never really understand the pros and cons offshore development. Software development is an activity who’s output is impossible to measure. As such we’ll never have hard numbers to prove one approach better than another. What we will see is growing qualitative feedback on the benefits of agility and offshore development – these qualitative assessments will determine if either, or both, will survive.”

There is also an interesting debate going on over Vincent Massol’s interview on Agile Offshore. http://www.theserverside.com/news/thread.tss?thread_id=23168#106090

Some good Agile Resources:
• Extreme Programming Intro
• Business Agile
• Agile Advice
• Agile in Action
• Manifesto for Agile Software Development
• Agile Alliance
• Agile Management Blog

P.S: A great article on Agile Software Development on Trizle titled How to Finish Big Projects  where the author emphasizes on creating crucial chunk first and then build outwards. 

No-progress intimations and expectation management

I have written earlier about the importance of managing expectations all around in project management – same applies to our work as well. I recently stumbled upon one such situation. We had to release a version of application for client review in the evening and the developer working on the administration module left for the day without updating me on the status. As it was to happen, I could not release that day and had to write an email to manage client’s expectations.  When quizzed the next day, he informed that the build was ready the previous evening – and he just guessed that I would know about it.

We usually send out progress report as the project progresses – but what do we do when the team has not made any progress? Rajesh Shetty suggests a great way to manage expectations at the other end in such cases – send “No-progress” report.

It is all about managing the expectation of the other party – it could be a simple email intimation, a call across the department or a “no-progress report”.

Power of Personal Communication

Experience is a great teacher they say – and they say it right. Some of my recent experiences on project/team communication have been learning lessons for me. I think it is really crucial to have sound communication practices (both personal communication as well as project communication) to make our work life easier.

The lessons? Here they go:

Too much of a formality in communication results in too much of a resistance. If you want to get your PC fixed, walk up to the system administrator (or call) and flash a friendly request and the job gets done faster. If the same thing is requested over an email with a copy to the infrastructure director, the person at the other end will surely get on a more defensive side and the work takes longer time to get done. Showing up and doing verbal communication reduces the information clutter and creates synergies. 

With personal communication, show that you care - for clients, for peers and for team members. It helps to talk often to the client – whenever we can. Important and crucial emails or deliveries to clients when complemented with a phone call not only gives the required clarity but also shows that you care. When someone in the team commits a mistake, it helps to walk upto him and give neccessary feedbacks – shows that you are concerned about it. Written word may or may not exhibit the real feeling.

One on one verbal communication is a great connector. Email communication is good for explicit and factual communication but when it comes to implicit and tacit communication, nothing can be as effective as verbal communication.