My Dad, Dr. C. Kesava Reddy MSc. PhD. has retired today from Directorate of Rice Research (Indian Council of Agricultural Research: Crop Science Division) as Principal Scientist. He was associated with DRR from early 70's.

We all congratulate him and wishing a enjoyable retirement days & a very Happy Birthday. 

It also happens to be my Father-in-law Mr.Narayana Reddy birthday today, so we all wish him a Very Happy Birthday.

Dad, Mom, Uncle & Aunty, You guys have done so much for each one of us, and we take a moment to thank you for everything. It is time that you relax and enjoy, we are here to take care of you.

Best Wishes from
Parvathi (Mom)
Shravan & Prabhavathi
Kiran & Smitha
Swapna Reddy & Ravindranath Reddy 
Narayana Reddy & Lakshmi Devi
Laxmana Rao & Ratna
Bhopal Reddy, Ramadevi & Kishore Kumar Reddy
Raghu, Ambica & Varun
Swetha
Vishwanath Reddy, Prasanna & Bharghava Teja
Ramakrishna Reddy & Kavitha Reddy
Ramakrishna Reddy, AdiLakshmi & Vishnuvardhan Reddy
Madhusudhan Reddy, Sudha, Hemanth Reddy & Monica Reddy
C.P.Reddy, Veni, VenkatSai Reddy & Srinivas Reddy (Minnu)
Vijay Reddy, Sridevi & Harshavardhan Reddy
Krishna Reddy, Bharathi, Yashwanth Reddy, Manoj Kumar Reddy
Balasubba Reddy, Bharathi & Shanthi Reddy
Gayathri Reddy, Sudhakar Reddy & Hemanth Reddy
Obula Reddy, Madduletamma
Mr & Mrs. Obula Reddy
Aruna Reddy & Himaja Reddy
Padmavathi Reddy, Narasimha Reddy & Samarsimha Reddy
Sudharshan reddy, Hymavathi & Cherishma Redy
Friends & Co-Workers at DRR, ICAR & IRRI

Photos to follow shortly...

If you want to vote, you have around week long time to think and vote. Here is the link http://www.new7wonders.com/

Lists are as old as humankind. It’s natural for us as creatures to enumerate items into an index (just ask David Letterman!). It’s what we do. Having spent several years managing corporate IT projects, I have seen many tactics used by fellow manager-soldiers. New project managers should heed the lessons of those that came before. Therefore, I emerge from the misty corners of the project arena, shake off the dust of combat and hereby present for the annals of history the 10 Undeniable Truths of Project Management.

1. Project Scope Is Not Defined On PowerPoint Slides
As hard as this is for people to swallow, a slide deck of 20 or so slides giving an overview of a project is not sufficient enough to define the scope. I can’t tell you how many times I have seen both project managers and high-powered consulting companies try to execute an engagement and want to rest upon their “project overview” presentation as the synthesis of what they will be delivering and, most importantly, what the customer will get their for their money. This never works and almost always leads to cost overruns. Project charters, scope documents and work breakdown structures are a better start. Not glamorous, but very effective.

2. Project Schedules Do Not Make a Project Plan
Too often, the new project manager believes that as long as he or she has a project schedule, they can raise that schedule like a shield to battle all forces against them in their project warfare. In reality, that schedule is but one tool that a PM needs. It states when something should be done and in what order. Project plans have more dimensions than just one. They need to have charters (to help make decisions and grant authority to the PM), management approaches, processes, issue logs, etc. Failing to have all of the tools necessary to manage a project is like having a tape measure, but no hammer or nails.

3. Projects Are Not Managed From Behind a Spreadsheet
Some project managers secretly want to be statisticians. They love to calculate all of the various metrics pertaining to their project such as the percentages of deliverables completed, tasks currently on schedule, tasks that should have started, of variance from budget, etc. These are all good to know. The problem is that they spend so much time summarizing and restating data in their spreadsheets, they never talk to the team members about how the project is going and what problems they are having. Without that connection with the team, they are not managing so much as they are reporting.

4. No Task Longer Than 80 Hours and Not Shorter Than 40
Avoid the temptation to place every single minute task into a plan. It will make assigning resources a nightmare and schedule changes even tougher. By sticking to a reasonable granularity of work, you will be better suited to “guide” what is going to happen in your project rather than trying to “control” what is happening.

5. No More Than One Person Responsible For a Task
It has been said that the true end-game of management is to delegate, thus delegation becomes the essence of management. To delegate means simply that I want you to do what I was doing. For me as a manager, to properly transfer that ownership and responsibility to someone else it needs to be a single person that I transfer to. If I delegate a task to a group of people, human nature dictates that in most cases each person will think the other person is taking point. If I delegate that same work to a single individual and empower him/her to coordinate with others as they see fit but the successful outcome is on his/her shoulders then I have stayed true to the tenets of delegation.

6. Every Task Generates a Deliverable. No Work for Work’s Sake.    
I have reviewed a lot of project plans that managers have created over the years. The one pet peeve that I have is tasks being inserted into a plan that contain too much “air”: tasks that seem to be loosely defined and even less explainable. I have a simple rule for any task that goes into a work plan: every task generates a deliverable. There is no work inserted into the schedule that doesn’t produce a tangible output. If there are “make work” tasks that don’t have an output, then that time should be consolidated into the work that produces a deliverable (e.g. meetings). There is an old adage, “don’t mistake activity for achievement.” Keep it simple--all work produces something, period.

7. Large projects should be broken down into sub-projects (if they have long timeframes)
As a project manager, you can’t properly control a large IT project ($5+ million) over multiple years as one large project. You have to break work down to manageable chunks. From the client point of view, you need to compartmentalize the work to the point where you can equate value delivered for the cost spent. Interim accomplishments also feed the projects team’s sense of success.

8. Plan for the Worst
The old saying is “the best laid plans of mice and men often go awry”, and they do. Always think through your risk plans. Even if things are going well, a good PM has to ask “what if?” Remember that for each risk you can think of, come up with a way to reduce the likelihood of it happening (mitigation) and have a Plan B if it does (contingency).

9. Make it Fun
IT projects can be daunting events. Have you ever noticed that there are some project managers that people just don’t want to work for? The Project Tyrant that is always changing things, asking for things at the last minute and making demands of people is someone that is hard to support over the long haul of a project. There will be tense times on any project, but the lead comes from the top. When things are at their worst, if the PM can laugh at himself it will relieve the tension of the entire team.

10. In the End it is People
In the end, the key point to be mindful of is that all of the previous techniques exist for one purpose: to produce results with a team of people. All of the techniques in the world will not produce anything if they are not constantly tuned, adjusted and calibrated for the individuals on your team. People are different and they all respond differently in various situations. The most successful senior managers I have run across in my experience were the ones with a unique respect, passion, appreciation and understanding for people.

Project managers that care for their team, can articulate a clear objective, are enthusiastic about what they are doing and can motivate others to be enthusiastic too will usually have far more success than they will have losses. Following these principles during your career on the project battlefield will leave you with a record to be proud of.

Source: www.gantthead.com

At the stroke of hour, I have submitted my PMI application, it took good 3+ hours to detail my PM Work experience and PM Education experience PDU's obtained from PMStudy.com. Waiting to hear from PMI on my application. Though I have plans to attempt the exam towards the end of the year. Baby steps...

My wife's birthday and our Wedding Anniversary get together photos

This is my first encrypted post, this encrypted post will not be visible to all, if you are interested to read this post, you have to contact me and get the key.

The preliminary scope statement document contains several elements, most of which are repeated in the final scope statement created during the Planning process group. So relax and just take a glance of the typically found 14 components.

1. Project and product objectives - Project objectives are the measurable success criteria of the project. Product objectives are the desired characteristics of the product, service, or result that the project was undertaken to create.
2. Product or service requirements and characteristics - These are conditions or capabilities that must be met or possessed by a system, product, service, result, or component to satisfy a contract, a standard, a specification, or other formally imposed documents.
3. Project boundaries - Project boundaries explicitly define what's included in and excluded from the project.
4. Project requirements and deliverables - Project requirements describe the conditions or capabilities that must be met or possessed by the project deliverables to satisfy stakeholder expectations. Project deliverables include the outputs of the project and auxiliary results, such as reports and documentation.
5. Product acceptance criteria - Product acceptance criteria include performance requirements and essential conditions that must be met before project deliverables are accepted.
6. Project constraints - A constraint is a state, quality, or sense of being restricted to a given course of action or inaction. It is an applicable restriction or limitation, internal or external to the project, that will affect the performance of the project or a process.
7. Project assumptions - Assumptions are factors that, for planning purposes, are considered to be true, real, or certain without proof or demonstration. Assumptions affect all aspects of project planning.
8. The initial project organization – the project organization consists of the project team members, project stakeholders, and performing organization.
9. The initial defined risks – Risks are possible events or conditions that would have a significant effect on the project outcome if they were to occur. Some risks, when matched with their possible outcomes, could lead to time and cost overruns.
10. Schedule milestones – Milestones are key events in the project schedule that may affect the project timeline. Schedule milestones also indicate the completion of a major deliverable. An example is the completion of a design prototype.
11. Initial work breakdown structure - A WBS is a hierarchical chart that shows the breakdown of a project's activities and deliverables. The initial WBS should consist of a "bare bones" outline of activities and deliverables.
12. The order-of-magnitude cost estimate – The order-of-magnitude cost estimate is one way to estimate the project's cost. It is an estimate that is made without detailed data.
13. Project configuration management requirements – Configuration Management requirements describe the degree to which configuration management and change control will be implemented on the project.
14. Approval requirements – Approval requirements outline approval processes and procedures that can be put in place by any stakeholder. Approval requirements can be applied to project objectives, deliverables, and work.

Internal Rate of Return by definition is the rate of return at which the Net Present Value of a stream of payments/incomes is equal to zero.

As you know, money devalues over time. The rate at which it does is commonly referred to as the "discount rate". Therefore, let's say you have a payment/income profile as shown below and we assume a discount rate of 7%. If you take the difference between the net present value of the payments and the net present value of the returns, you get the net present value of the investment. In the case shown below that turns out to be $70,000 - $68,755.45 = $1,244.55.

Now the question is: at what discount rate would the net present value of my investment be zero? In other words, at what rate would money have to devalue at in order to make my investment (i.e., payments vs. income) worth nothing in net present value terms. In the case shown below, that discount rate would be 8.66% and therefore, 8.66% is the Internal Rate of Return for the above described payment/income stream.

So why is this important? Well, it is important because you have now learned that if money devalues at 8.66% you make nothing on your Project. Ya, so what? Well, if you knew of a place where you could--without question--invest your money and get 8.66% return on your Project and you held on to your money and didn't invest it, then your money would be devaluing at a rate of 8.66% regardless of the going market discount rate.

Now, if you chose to not invest your money in the Project that would earn you 8.66% return because you knew of another Project that would earn you 10.24% return (without question), then you'd be exercising good judgment, no! Yes! And that is why comparing Internal Rates of Return is a good way to decide where to invest your money.

When choosing between projects or when choosing alternative methods of doing the project, projects with higher IRR values are generally considered better than projects with low IRR values.

For the exam, you need to know three things concerning IRR:

• IRR is the discount rate when NPV equals zero.
• IRR assumes that cash inflows are reinvested at the IRR value.
• You should choose projects with the highest IRR value.

Projects may begin with a company investing some amount of money into the project to complete and accomplish its goals. In return, the company expects to receive revenues, or cash inflows, from the resulting project. Net present value (NPV) allows to calculate an accurate value for the project in today’s dollars. I realized that the mathematical formula for NPV is complicated, and not worth remembering it, instead remember how to calculate the calculate NPV by simple means. 

Net present value works like discounted cash flows in that you bring the value of future money received into today’s dollars. With NPV, you evaluate the cash inflows using the discounted cash flow technique applied to each period the inflows are expected instead of in one sum. The total present value of the cash flows is then deducted from your initial investment to determine NPV. NPV assumes that cash inflows are reinvested at the cost of capital.

Here’s the rule: If the NPV calculation is greater than zero, accept the project. If the NPV calculation is less than zero, reject the project.

Let's look at few examples, Project A and Project B have total cash inflows that are the same at the end of the project, but the amount of inflows at each period differs for each project, with a 12 percent cost of capital.

Project A

Project A has an NPV greater than zero and should be accepted. Project B has an NPV less than zero and should be rejected. When you get a positive value for NPV, it means that the project will earn a return at least equal to or greater than the cost of capital.

Another note on NPV calculations: Projects with high returns early in the project are better projects than projects with lower returns early in the project. In the preceding examples, Project A fits this criterion also.

Last week, my Mom, Dad & Sister have been on a week long trip to Kashmir, Golden Temple, Wagha border and other places and here are few pictures taken during the trip.

The Payback Period is defined as the length of time required to recover an initial investment through cash flows generated by the investment. The Payback Period lets you see the level of profitability of an investment in relation to time. Inflation or interest earned in not considered in this technique. The shorter the time period the better the investment opportunity.

As an example, consider the implementation of a Human Resources (HR) software application that costs $150,000 and will generate $50,000 in annual savings in four years (the project duration):

HR Application Example

The Payback Period is calculated by comparing the annual benefits of an investment with the amount of the initial investment. Using the formula above, the Payback Period is calculated to be three years by dividing the initial investment of $150,000 over the annual cash flows of $50,000.

The equation above can only be used when the cash flows are the same every year for the duration of the project. If the initial investment is spread out over several years, or the benefits change over time, then the Payback Period is calculated by looking at the Net Benefits, using the formula below: 

Now consider the software implementation with the same initial cost but with variable annual cash flows:

HR Application Example

Given the variable cash flows, the payback is calculated by looking at the cash flows and establishing the year the investment is paid off. At the beginning of Year 2, the company has recovered $120,000 of the original $150,000. At the end of Year 2, the remaining $30,000 is recovered with the cash flow of $40,000 earned during this period. The payback period is then 2 + ($30000/$40000) or 2.8 years.

The first step is to determine the Net Benefits. The Net Benefits are equal to the Benefits minus any initial or remaining Costs:

The Payback Period is then calculated by dividing the Net Benefits of the final year in which there is a negative cash flow (no profits) by the total cash flow for the subsequent (profitable) year. This ratio is added to the final year of negative cash flow. In the example above, Year 2 is the last year with a negative cash flow and the Payback Period is 2 + ($30,000 / $40,000) or 2.8 years.

The payback period also gives some indication of the level of risk of a project by separating projects that require a short time to recover their investment from those that require a longer time period. Companies use Payback Period methodology as an initial screening tool to determine the profitability of investments.

Money received in the future is worth less than money received today. The reason for that is the time value of money. If $2,000 is borrowed from me today and promised to pay it back in three years, I would expect you to pay interest in addition to the original amount borrowed.

Okay, if you were a family member or a really close friend maybe you wouldn’t, but ordinarily this is the way it works. I would have had the use of the $2,000 had I not lent it to someone. If I had invested the money, I’d receive a return on it. Therefore, the future value of the $2,000 lent today is $2,315.25 in three years from now at 5 percent interest per year. Here’s the formula for future value calculations:

This formula says the future value (FV) of the investment equals the present value (PV) times (1 plus the interest rate) raised to the value of the number of time periods (n) the interest is paid. Let’s plug in the numbers:

FV = 2,000(1.05)³

FV = 2,000(1.157625)

FV = $2,315.25

The discounted cash flow technique compares the value of the future cash flows of the project to today’s dollars. In order to calculate discounted cash flows, you need to know the value of the investment in today’s terms, or the present value (PV). PV is calculated as follows:

• DPV is the discounted present value of the future cash flow (FV), or FV adjusted for the opportunity cost of future receipts and risk of loss;
• FV is the nominal value of a cash flow amount in a future period;
• d is the discount rate, which is the opportunity cost plus risk factor (or the time value of money: “i” in the future-value equation);
• n is the number of discounting periods used (the period in which the future cash flow occurs). I.e. if the receipts occur at the end of year 1, n will be equal to 1; at the end of year 2, 2—likewise, if the cash flow happens instantly, n becomes 0, rendering the expression an identity (DPV=FV).

This is the reverse of the FV formula talked about earlier. So, if we ask the question, "What is $2,315.25 in three years from now worth today given a 5 percent interest rate?" we’d use the preceding formula. Let’s try it:

PV = $2,315.25 ÷ (1 + .05)³

PV = $2,315.25 ÷ 1.157625

PV = 2,000

$2,315.25 in three years from now is worth $2,000 today.

Discounted cash flow is calculated just like this for the projects you’re comparing for selection purposes or when considering alternative ways of doing the project. Apply the PV formula to the projects you’re considering and then compare the discounted cash flows of all the projects against each other to make a selection. Here is an example comparison of two projects using this technique:

Project A is expected to make $100,000 in two years.

Project B is expected to make $120,000 in three years.

If the cost of capital(Interest rate) is 12 percent, which project should PMO choose?

Using the PV formula PV = FV ÷ (1 + i)n, project’s worth can be calculated as

The PV of Project A is 100000/(1+0.12)² = $79,719.

The PV of Project B is 120000/(1+0.12)³ = $85,414.

Project B is the project that will return the highest investment to the company and should be chosen over Project A.

The Project charter is created at the very start of the project. It is an ideal place to document the relationships between the project and the organizational strategy. The project manager does not need to write the charter, but the project manager has a role in the process. The project manager needs to demand an adequate charter, and be prepared to create one for the sponsor, if the sponsor does not provide it on his or her own. The project charter recognizes the existence of a project in the organization. A project sponsor, who is usually external to the organization, issues the charter. The project sponsor is the individual or organization that funds the project.

A Project charter should be simple, straightforward, and short, but it must contain certain key elements. Once the basic components of a charter are clear, it is possible to give it a central role in the organization. The charter has a critical influence on any application of organizational strategy, organizational project maturity, program management, and portfolio management.

Project Charter is a document issued by the project initiator or sponsor that formally authorizes the existence of a project, and provides the project manager with the authority to apply organizational resources to project activities. The key word in this definition is "authority". It authorizes both the project and the project manager.

The charter is created at the Initiation phase, before significant resources are assigned. An early project charter should typically be short, perhaps a few pages in length, details of implementation are not known yet. They can be as short as a part of a single page, so long as they clearly provide authority to the project and project manager.

A charter is ideal for critically examining whether a project truly supports organizational strategy. The project is new, so investment is low. If the project is not truly aligned with organizational strategy, the charter is the best chance to stop that project before resources are wasted. If project managers consistently stopped misaligned projects before they started, there would be far fewer failed projects.

Ensure Common Understanding and Set Expectation

Project manager should ensure that all project stakeholders have a common understanding of
the project’s requirements and its objective. The project charter ensures that all stakeholders have a
common understanding regarding:

• Requirements
• Business needs
• Summary schedule (The start and end date of the project)
• Assumptions and constraints
• Business case, including return on investment
• The budget and other resources that will be available for the project
• The acceptance criteria for the project

After establishing a common understanding, the project manager and the project team should set the expectations regarding:

• How the project objective be achieved
• Who will perform the key roles
• What is the authority of the key persons
• What will be the key steps
• When and how frequently will project performance be shared
• How will issues be raised and to what forum

This list is normative, providing guidance on what a charter should provide.

Some project managers may be misled by the word document in the definition and by the specific list of information in PMBOK. They fear that they do not have a project charter unless they have a specific document formatted with certain headings. PMBOK Guide does not mandate the use of any specific document format, and project charters can take many forms. Often the charter appears in the form of a free-form e-mail or memo.

The definition itself gives the critical questions that determine, Does a project have a charter? These questions are:

• Does the sponsor know the project exists, and does the sponsor agree that it should exist? (authorize existence)
• Does the sponsor know who the project manager is and does he or she support that person’s leadership of the project? (authorize the project manager)
• Has the sponsor given the project manager authority over money, people, and other organizational resources, in order to accomplish that project? (authority to apply resources)
• Has the sponsor ever written an e-mail, written a memo, spoken at a meeting (preferably a meeting with documented minutes) indicating, even implicitly, a "Yes" answer to the questions above?

A "yes" answer to these questions means that the project has a charter. Restated this way, it is clear that all successful projects must at some point have been chartered. If a project were not chartered, the project manager would likely be held accountable for insubordination if he or she expended any time, money, or other resources on it. In most organizations, it is not possible to make progress without authorization from someone.

Can be Multiple Documents
A project charter does not need to be contained in a single document. Ideally, one document will authorize the effort and include references to other documents that show business need, milestone schedule, and other key information. If authority has been provided, and the sponsor has approved project-related documents that include all of that information, then that collection of documents effectively forms the charter. Even if they do not explicitly cross-reference each other, the collection of documents can be considered a charter.

In many companies that perform project work on behalf of clients, the work order may serve as a key component of the project charter. In these companies, the work order gives specific people authority over organizational resources. The signature of a customer at the bottom conveys authority from the customer-side, and the counter-signature of an officer of the consultancy makes the agreement binding on the consultant-side. Work orders often provide short explanations of the scope of the work, or they refer to more detailed specifications. Work orders can serve as a self-contained project charter or a component of a charter.

Not Written by the Sponsor
Sponsors are often senior executives with little time. Expecting them to write and deliver a complete project charter may be impossible for even a project-oriented organization. The project manager should be prepared to drafting or even writing the final copy for the charter. The sponsor must authorize it, not write it. Depending on the company, authorization may be delivered by a formal signature, a formal chartering ceremony, or simply a reply e-mail saying, “I agree. Proceed.”

For projects that are sponsored by a committee or a group of people, it is particularly impractical to have the sponsors author the charter. Typically the project manager or one of the sponsors will write the document and the others will approve it.

“My Boss Just Told Me To Do It”
It is common when the project manager’s direct manager authorizes the project, for the project manager to feel that there is no charter. In all likelihood the project manager has the strongest charter that anyone could ask for. When a manager tells a subordinate to start a project, the lines of control and authority are clear. The initial assignment may be informal and undocumented, but the manager will typically reinforce that charter in writing and verbally on a regular basis through status reports, formal meetings, and informal discussions. Normal day-to-day work will lead to some documentation of the assignment. The manager will usually issue a written statement at some point making clear that the project has been authorized. When the manager provides documents about the desired results, the manager is documenting requirements, business needs, and other parts of the project charter. This document trail is the project charter.

Some managers rarely create documents about assignments, though. Project managers who work for these managers should consider writing a brief e-mail or note confirming the conversation that started the project. The note might begin, “As we discussed earlier today…” and follow with notes from the conversation and a summary of key documents the manager provided.

Some project-management experts might argue that the manager needs to at least confirm in writing, “Yes, I agree,” for that note to be a charter. Documentation makes it stronger and is highly recommended, but a project can be successfully chartered, executed, and completed even without that documentation. An orally-communicated charter is still a charter. If the project manager honestly got the assignment and the authorization of resources, even verbally, the project should be considered chartered.

“We Are Not Done With Requirements”
In order to issue a charter at the very start of a project, the charter’s author must create it based on only partial information. The PMBOK Guide recommends including “requirements,” “schedule,” and “budget,” but it will be impossible to give detailed versions of any of these pieces of information at the very start. Instead, prepare the charter based on the limited information available at the time.