Risk and Issue - Thoughts

Schedule Creation
Schedule, resources, and product definition have all been dictated by the customer or upper management and are not in balance.
Schedule is optimistic, "best case," rather than realistic, "expected case."
Schedule omits necessary tasks.
Schedule was based on the use of specific team members, but those team members were not available.
Cannot build a product of the size specified in the time allocated.
Product is larger than estimated (in lines of code, function points, or percentage of previous project’s size).
Effort is greater than estimated (per line of code, function point, module, etc.).
Re-estimation in response to schedule slips is overly optimistic or ignores project history
Excessive schedule pressure reduces productivity.
Target date is moved up with no corresponding adjustment to the product scope or available resources.
A delay in one task causes cascading delays in dependent tasks.
Unfamiliar areas of the product take more time than expected to design and implement.

Organization and Management
Project lacks an effective top-management sponsor.
Project languishes too long in fuzzy front end.
Layoffs and cutbacks reduce team’s capacity.
Management or marketing insists on technical decisions that lengthen the schedule.
Inefficient team structure reduces productivity.
Management review/decision cycle is slower than expected.
Budget cuts upset project plans.
Management makes decisions that reduce the development team’s motivation.
Non-technical third-party tasks take longer than expected (budget approval, equipment purchase approval, legal reviews, security clearances, etc.).
Planning is too poor to support the desired development speed.
Project plans are abandoned under pressure, resulting in chaotic, inefficient development.
Management places more emphasis on heroics than accurate status reporting, which undercuts its ability to detect and correct problems.

Development Environment
Facilities are not available on time.
Facilities are available but inadequate (e.g., no telephone, network wiring, furniture, office supplies, etc.)
Facilities are crowded, noisy, or disruptive.
Development tools are not in place by the desired time.
Development tools do not work as expected; developers need time to create workarounds or to switch to new tools.
Development tools are not chosen based on their technical merits, and do not provide the planned productivity.

End Users
End user insists on new requirements.
End user ultimately finds product to be unsatisfactory, requiring redesign and rework.
End user does not buy into the project and consequently does not provide needed support.
End user input is not solicited, so product ultimately fails to meet user expectations and must be reworked.

Customer
Customer insists on new requirements.
Customer review/decision cycles for plans, prototypes, and specifications are slower than expected.
Customer will not participate in review cycles for plans, prototypes, and specifications or is incapable of doing so—resulting in unstable requirements and time-consuming changes.
Customer communication time (e.g., time to answer requirements-clarification questions) is slower than expected.
Customer insists on technical decisions that lengthen the schedule.
Customer micro-manages the development process, resulting in slower progress than planned.
Customer-furnished components are a poor match for the product under development, resulting in extra design and integration work.
Customer-furnished components are poor quality, resulting in extra testing, design, and integration work and in extra customer-relationship management.
Customer-mandated support tools and environments are incompatible, have poor performance, or have inadequate functionality, resulting in reduced productivity.
Customer will not accept the software as delivered even though it meets all specifications.
Customer has expectations for development speed that developers cannot meet.

Contractors
Contractor does not deliver components when promised.
Contractor delivers components of unacceptably low quality, and time must be added to improve quality.
Contractor does not buy into the project and consequently does not provide the level of performance needed.

Requirements
Requirements have been base lined but continue to change.
Requirements are poorly defined, and further definition expands the scope of the project.
Additional requirements are added.
Vaguely specified areas of the product are more time-consuming than expected.

Product
Error-prone modules require more testing, design, and implementation work than expected.
Unacceptably low quality requires more testing, design, and implementation work to correct than expected.
Development of the wrong software functions requires redesign and implementation.
Development of the wrong user interface results in redesign and implementation.
Development of extra software functions that are not required (gold plating) extends the schedule.
Meeting product’s size or speed constraints requires more time than expected, including time for redesign and re-implementation.
Strict requirements for compatibility with existing system require more testing, design, and implementation than expected.
Requirements for interfacing with other systems, other complex systems, or other systems that are not under the team’s control result in unforeseen design, implementation, and testing.
Pushing the computer science state-of-the-art lengthens the schedule unpredictably.
Requirement to operate under multiple operating systems takes longer to satisfy than expected.
Operation in an unfamiliar or unproved software environment causes unforeseen problems.
Operation in an unfamiliar or unproved hardware environment causes unforeseen problems.
Development of a kind of component that is brand new to the organization takes longer than expected.
Dependency on a technology that is still under development lengthens the schedule.

External Environment
Product depends on government regulations, which change unexpectedly.
Product depends on draft technical standards, which change unexpectedly.

Personnel
Hiring takes longer than expected.
Task prerequisites (e.g., training, completion of other projects, acquisition of work permit) cannot be completed on time.
Poor relationships between developers and management slow decision-making and follow through.
Team members do not buy into the project and consequently does not provide the level of performance needed.
Low motivation and morale reduce productivity.
Lack of needed specialization increases defects and rework.
Personnel need extra time to learn unfamiliar software tools or environment.
Personnel need extra time to learn unfamiliar hardware environment.
Personnel need extra time to learn unfamiliar programming language.
Contract personnel leave before project is complete.
Permanent employees leave before project is complete.
New development personnel are added late in the project and additional training and communications overhead reduces existing team members’ effectiveness.
Team members do not work together efficiently.
Conflicts among team members result in poor communication, poor designs, interface errors and extra rework.
Problem team members are not removed from the team, damaging overall team motivation.
The personnel most qualified to work on the project are not available for the project.
The personnel most qualified to work on the project are available for the project but are not used for political or other reasons.
Personnel with critical skills needed for the project cannot be found.
Key personnel are available only part time.
Not enough personnel are available for the project.
People’s assignments do not match their strengths.
Personnel work slower than expected.
Sabotage by project management results in inefficient scheduling and ineffective planning.
Sabotage by technical personnel results in lost work or poor quality and requires rework.

Design and Implementation
Overly simple design fails to address major issues and leads to redesign and re-implementation.
Overly complicated design requires unnecessary and unproductive implementation overhead.
Inappropriate design leads to redesign and re-implementation.
Use of unfamiliar methodology results in extra training time and in rework to fix first-time misuses of the methodology.
Product is implemented in a low-level language (e.g., assembler), and productivity is lower than expected.
Necessary functionality cannot be implemented using the selected code or class libraries; developers must switch to new libraries or custom-build the necessary functionality.
Code or class libraries have poor quality, causing extra testing, defect correction and rework.
Schedule savings from productivity enhancing tools are overestimated.
Components developed separately cannot be integrated easily, requiring redesign and rework.

Process
Amount of paperwork results in slower progress than expected.
Inaccurate progress tracking results in not knowing the project is behind schedule until late in the project.
Upstream quality-assurance activities are shortchanged, resulting in time-consuming rework downstream.
Inaccurate quality tracking results in not knowing about quality problems that affect the schedule until late in the project.
Too little formality (lack of adherence to software policies and standards) results in miscommunications, quality problems, and rework).
Too much formality (bureaucratic adherence to software policies and standards) results in unnecessary, time-consuming overhead).
Management-level progress reporting takes more developer time than expected.
Half-hearted risk management fails to detect major project risks.
Software project risk management takes more time than expected.

Project Management

I. Are the cost/benefits clearly defined with a documented write-up?
1. Yes, a cost/benefit analysis has been performed by a qualified, experienced resource
2. Yes, a cost/benefit analysis has been performed by an entity not necessarily having experience
3. Cost/benefits have been informally derived but not clearly documented
4. No cost/benefit analysis has been performed yet

II. Have metrics been established to verify the successful completion of each project phase?
1. Metrics have been established for each phase of the project
2. Metrics have been established for the first phase of the project
3. Metrics to determine the success of the total project have been established but not specific to a phase
4. No metrics have been established to ensure successful project completion

III. Have scope changes occurred which appear to exert pressure on schedule demands?
1. No scope changes have occurred
2. Yes, but only small changes have been made and have been well documented
3. Yes, significant scope changes have been made and have been well documented
4. Yes, significant changes have been made and have not been clearly documented

IV. How clearly are the expected project outcomes defined?
1. Expected outcomes are well defined
2. Expected outcomes are minimally defined
3. Overall project outcomes are broadly defined
4. Outcomes are not clearly defined or contain little detail

V. How is the training plan being developed?
1. Training plan is being developed with comprehensive input from stakeholder and vendor experts
2. Training planning is being developed with limited input from stakeholder and vendor experts
3. Training planning is being developed based upon prior experiences but no formal methodology
4. Training planning has not yet been completed

VI. How is the testing plan being developed?
1. Test planning is being developed with comprehensive input from stakeholder and vendor experts
2. Test planning is being developed with limited input from stakeholder and vendor experts
3. Test planning is being developed based upon prior experiences but no formal methodology
4. Test planning has not yet been completed

VII. How much control does IT have over the schedule?
1. Start/end dates are flexible & established by project plan
2. Start/end dates established mutually by vendor & BHS IT
3. Start/end dates established mutually by vendor & BHS IT
4. Start/end dates set by vendor; penalty clauses exist

VIII. How much input did BHS IT have in developing the deliverables?
1. We developed the deliverables for the shareholder
2. We guided the shareholder in developing deliverables
3. We were asked for comments after deliverables were developed
4. We had no involvement in developing deliverables

IX. Is the project required before other projects can proceed?
1. Not at all
2. Indirectly
3. Directly at < 50% units or departments
4. Directly at >50% units or departments

X. Is there a plan for ensuring that deliverables meet the need of the users?
1. There is a plan to ensure that the needs of the users are thoroughly met
2. The plan for verification of user deliverables is nearly complete
3. The plan for ensuring user deliverables is in the conceptual phase
4. There is no plan for ensuring that deliverables meet users needs

XI. What are the IT and Technical project coordinators' overall opinion of project risk?
1. Risk is minimal
2. Risk is moderate
3. Risk is significant
4. Risk is major

XII. To what degree are changes to the current business processes being managed?
1. There is a well-documented plan in place for the redesign of the changed processes with a detailed rollout schedule
2. There is a well-documented plan in place for the redesign of the changed processes but a detailed rollout schedule has not yet been developed
3. New process changes have been considered but are not clearly defined and documented
4. Process changes have not yet been considered

XIII. To what degree are changes to the current IT processes being managed?
1. There is a well-documented plan in place for the redesign of the changed processes with a detailed rollout schedule
2. There is a well-documented plan in place for the redesign of the changed processes but a detailed rollout schedule has not yet been developed
3. New process changes have been considered but are not clearly defined and documented
4. Process changes have not yet been considered

XIV. To what degree are changes to the current patient care processes being managed?
1. There is a well-documented plan in place for the redesign of the changed processes with a detailed rollout schedule
2. There is a well-documented plan in place for the redesign of the changed processes but a detailed rollout schedule has not yet been developed
3. New process changes have been considered but are not clearly defined and documented
4. Process changes have not yet been considered

XV. To what degree are the project team and stakeholder skill requirements well defined?
1. Skill requirements with corresponding time frame requirements have been clearly documented for all phases of the project
2. Skill requirements have been clearly documented for all phases of the project but do not include corresponding time frame requirements
3. Skill requirements are loosely defined for the project
4. Skill requirements are vague or not well defined for the project

XVI. To what degree have critical milestones been established for this project?
1. Clearly measurable and achievable milestones with firm dates have been created throughout the entire project lifecycle
2. Milestones, although not clearly measurable, with firm dates have been set for part of the project
3. Milestones have been created for the project but dates are not firmly set
4. No milestones exist at this time

XVII. To what degree have 'open issues' been tracked and included as part of ongoing management processes?
1. There is proven method of issue tracking and resolution currently in place and is widely used by all parties
2. There is a method of issue tracking and resolution currently in place and is generally used by all parties
3. Open issues are dealt with on an item by item basis and are not tracked using a standard method
4. There is no clear issue tracking or resolution approach in use on the project

XVIII. To what extent has a project plan been developed for the entire project lifecycle?
1. A detailed project plan has been created using an industry accepted methodology and experience from projects of similar size and scope
2. A project plan has been created using detailed project estimates; but not based on a comparable project
3. A project plan has been created using general areas of the project lifecycle, but there is not a clear understanding yet of the needed resources
4. No project plan exists at this time.

Project Resources
I. Does the project management team have relevant experience?
1. Members of the project management team have experience leading projects of similar size and complexity
2. Members of the project management team have had exposure to projects of similar size and complexity but not in lead roles
3. Members of the project management team have had limited exposure to projects of similar size and complexity and generally lack detailed knowledge
4. Members of the project management team have no experience with projects of similar size and complexity

II. How complex is coordination of internal resources?
1. Internal project - no hospital resources
2. Small project - internal and few hospital resources
3. Medium project - internal and multiple hospital resources
4. Large project - significant internal and hospital resources

III. Is the project team organized and deployed to a single location?
1. All team members are together with daily interactions with the users
2. All team members are located together but have limited user contact
3. Team members are in multiple locations but meet regularly
4. Team is located off site and rarely gets together as a whole

Project Size and Duration
I. How severe would be the result of late delivery?
1. No noticeable disruption of the business
2. Some disruption to limited, non-critical areas of the business
3. Some disruption to critical, time-valued areas of the business
4. Major disruption to the business because the new system is critical to the core business functions

II. What are the number of affected stakeholders per facility?
1. <10
2. >10 and < 50
3. > 50 and < 100
4. > 100

III. What is the Project Priority?
1. Minimal
2. Moderate
3. Significant
4. Major

IV. What is the amount of time the SPO can spend on the project?
1. 50% or greater
2. <50% and > 35%
3. < 35% and > 25%
4. < 25%

V. What is the impact of Go Live date(s) on other projects?
1. No projects are affected
2. A minimum number of projects and related resources are affected
3. A minimum number of projects are affected, but there are resource allocation conflicts
4. There are conflicts with other projects and resource allocations

VI. What is the number of affected facilities?
1. 1
2. 2 to 3
3. 3 to 4
4. All

VII. What is the total elapsed time of the project from start to finish?
1. < 3 months
2. > 3 months and < 6 months
3. > 6 months and < 1 year
4. One year or more

VIII. Will multiple business units be affected by the new system?
1. There will only be one business unit affected
2. Multiple business units within the same hospital will be affected
3. One business unit (each) in several hospitals will be affected
4. Multiple business units in several hospitals will be affected

IX. Will multiple patient care units be affected by the new system?
1. There will only be one patient care unit affected
2. Multiple patient care units within the same hospital will be affected
3. One patient care unit (each) in several hospitals will be affected
4. Multiple patient care units in several hospitals will be affected

Project Stakeholders
I. Are affected stakeholders willing to accept change created by this project?
1. Stakeholders are well informed about the change and show strong enthusiasm
2. Probably, stakeholders seems enthusiastic but there has been no formal evaluation of their enthusiasm or detailed knowledge of the change
3. Unclear, only limited or informal feedback from stakeholders have been received
4. No, firsthand feedback clearly indicates reluctance to the change

II. How committed is the hospital to the project?
1. All affected hospitals have assigned people and budgeted time
2. All affected hospitals have assigned people but has not budgeted time
3. More than half of affected hospitals have assigned people and budgeted time
4. Less than half of affected hospitals have assigned people and budgeted time

III. How does the project affect financial systems?
1. Not at all
2. Indirectly
3. Directly at < 50% units or departments
4. Directly at > 50% units or departments

IV. How does the project affect human resource systems?
1. Not at all
2. Indirectly
3. Directly at < 50% units or departments
4. Directly at > 50% units or departments

V. How does the project affect patient care systems?
1. Not at all
2. Indirectly
3. Directly at < 50% units or departments
4. Directly at > 50% units or departments

VI. What is the level of stakeholders involvement in the project?
1. The stakeholders are involved and have a permanent representative presence on the project team
2. The stakeholders are available for consultation and to provide functional advice
3. The stakeholders are minimally engaged on the project and clarification of requirements is difficult
4. The stakeholders are not involved in the project

VII. What will be the magnitude of change that the new system will impose upon the business stakeholders?
1. The new system will impose very little change, if any, upon the stakeholders
2. The new system will change slightly the current daily operations of the stakeholders
3. The new system will require significant changes by the stakeholders and will require training
4. The new system will present an entirely new way for the stakeholders to complete daily operations

VIII. What will be the magnitude of change that the new system will impose upon the patient care stakeholders?
1. The new system will impose very little change, if any, upon the stakeholders
2. The new system will change slightly the current daily operations of the stakeholders
3. The new system will require significant changes by the stakeholders and will require training
4. The new system will present an entirely new way for the stakeholders to complete daily operations

IX. Will staff numbers be reduced as a result of implementing the system?
1. There will not be a reduction in staff as a result of the new system
2. A small number of reductions are expected to isolated areas of the organization
3. Numerous reductions are expected to several levels of the organization
4. Staffing projections have not been completed

Project Support
I. Is the current Client Server and Operating Systems structure prepared to support the new system?
1. C/S and OS have significant experience in managing similar environments and will require little or no training
2. C/S and OS have experience with similar environments, but will probably require some degree of training
3. C/S and OS have limited or no experience with the environment and will require extensive training to be effective
4. C/S and OS does not have the expertise required to manage the operations and new resources will have to be hired or contracted

II. Is the current Clinical Support structure prepared to support the new system?
1. Clinical Support has significant experience in managing similar environments and will require little or no training
2. Clinical Support has experience with similar environments, but will probably require some degree of training
3. Clinical Support has limited or no experience with the environment and will require extensive training to be effective
4. Clinical Support does not have the expertise required to manage the operations and new resources will have to be hired or contracted

III. Is the current Data Base & Integration structure prepared to support the new system?
1. Data Base & Integration has significant experience in managing similar environments and will require little or no training
2. Data Base & Integration has experience with similar environments, but will probably require some degree of training
3. Data Base & Integration has limited or no experience with the environment and will require extensive training to be effective
4. Data Base & Integration does not have the expertise required to manage the operations and new resources will have to be hired or contracted

IV. Is the current Financial Support structure prepared to support the new system?
1. Financial Support has significant experience in managing similar environments and will require little or no training
2. Financial Support has experience with similar environments, but will probably require some degree of training
3. Financial Support has limited or no experience with the environment and will require extensive training to be effective
4. Financial Support does not have the expertise required to manage the operations and new resources will have to be hired or contracted

V. Is the current Help Desk structure prepared to support the new system?
1. The Help Desk has significant experience in managing similar environments and will require little or no training
2. The Help Desk has experience with similar environments, but will probably require some degree of training
3. The Help Desk has limited or no experience with the environment and will require extensive training to be effective
4. The Help Desk does not have the expertise required to manage the operations and new resources will have to be hired or contracted

VI. Is the current Networking and Telecom structure prepared to support the new system?
1. Networking has significant experience in managing similar environments and will require little or no training
2. Networking has experience with similar environments, but will probably require some degree of training
3. Networking has limited or no experience with the environment and will require extensive training to be effective
4. Networking does not have the expertise required to manage the operations and new resources will have to be hired or contracted

VII. Is the current Operations structure prepared to support the new system?
1. Operations has significant experience in managing similar environments and will require little or no training
2. Operations has experience with similar environments, but will probably require some degree of training
3. Operations has limited or no experience with the environment and will require extensive training to be effective
4. Operations does not have the expertise required to manage the operations and new resources will have to be hired or contracted

VIII. Is the current Web Development structure prepared to support the new system?
1. Web Development has significant experience in managing similar environments and will require little or no training
2. Web Development has experience with similar environments, but will probably require some degree of training
3. Web Development has limited or no experience with the environment and will require extensive training to be effective
4. Web Development does not have the expertise required to manage the operations and new resources will have to be hired or contracted

Technological
I. Do the key technologies appear to be the appropriate foundation given the system design?
1. There is every reason to believe that the proposed technology represents a solid foundation for the foreseeable future.
2. Certain components may reach the end of their lifecycle before the system does, but there is a high probability that there will be an upgrade path for replacement
3. Certain components may reach the end of their lifecycle before the system does and there does not appear to be a logical upgrade path
4. Various components appear to have reached the end of their lifecycle and more advanced technology exists in the market or technology foundation has yet to be determined

II. Does the project replace current system hardware?
1. No
2. Unknown
3. Yes


III. Does the project require conversions of current data systems?
1. No
2. Unknown

3. Yes

IV. Does the project’s technology (software, hardware, etc.) conflict with current BHS technology?
1. No
2. Unknown
3. Yes


V. Has (or will) the functionality of software be tested?
1. No
2. Unknown
3. Yes


VI. How clearly defined are the system operating procedures (backups, restart/recovery, etc.)?
1. Well defined with easy, well-documented, legible procedures
2. Maintenance procedures exist and some documentation exists
3. Maintenance procedures exist but documentation is limited
4. System maintenance procedures are not clearly defined or documented

VII. How many existing computer systems must the project system interact with?
1. A limited number of interfaces
2. A moderate number of interfaces
3. A large number of interfaces
4. The number of interfaces is not known

VIII. How mature are the technologies & products in this project?
1. All technologies/products are mature
2. Few technologies/products are new
3. Many (30-69%) of technologies/products are new
4. Most (70% or more) technologies/products are new

IX. How severely would business be impacted by a system failure?
1. Minimal impact-system is not critical to daily patient care or business functions
2. Moderate impact-system is critical to patient care or business, but a well-documented, automated contingency approach exists
3. Significant impact-system is critical to patient care or business and contingency plan relies on work-around
4. Severe impact-system is critical to patient care or business and there is no well-documented contingency plan

X. How thoroughly have the technology options been evaluated?
1. Experienced technical specialists performed a comprehensive evaluation of options using a proven methodology
2. Experienced technical specialists made recommendations based on prior experiences
3. Key functional personnel made recommendations for the options
4. A detailed evaluation has not yet been performed

XI. Is the project required to update old technology?
1. No
2. Unknown
3. Yes


XII. Is the proposed hardware/software environment in production already within the organization? (i.e. mainframe, client server, middleware, etc.)
1. The environment is in production and well established
2. The environment is currently in use in production but not well-established and subject to changes
3. The environment is currently in use for development efforts but has not yet been established in production
4. Hardware/software environment is not currently in use

XIII. Is there a system load test or other measures to ensure good system performance (i.e. measures to test response time, system efficiency, etc.)?
1. There is a load test for system performance in accordance with accepted industry standards
2. There is a methodology for load testing but some phases are not complete
3. The load testing plans have been discussed, but are not in place at this time
4. There are no plans for load testing the system.

XIV. To what extent will the new system enable de-installation of the existing system?
1. The new system will completely replace an existing system or an existing system does not exist
2. The new system will be a new layer that will lead to the eventual replacement of an existing system
3. The new system will be a new layer and there is not a business case for the elimination of any existing systems
4. The new system will be run in parallel to an existing system

XV. What knowledge level does the Technical project team members have for the proposed technology environment?
1. The proposed platform is well understood by the project team and any technical difficulties that emerge are likely to be handled in-house
2. There are parts of the platform that are very clearly understood, however, aspects of the new platform will be seen for the first time.
3. The platform is not well known to the project team but specialized expertise is readily available from vendors
4. The platform is not well know to the project team and specialized expertise is not easily available

Project Vendors
I. Does the vendor project management team have relevant experience?
1. Members of the vendor project management team have experience leading projects of similar size and complexity
2. Members of the vendor project management team have had exposure to projects of similar size and complexity but not in lead roles
3. Members of the vendor project management team have had limited exposure to projects of similar size and complexity and generally lack detailed knowledge
4. Members of the vendor project management team have no experience with projects of similar size and complexity

II. How complex is coordination of external resources?
1. No subcontractors or vendors to manage
2. One or two subcontractors / vendors to manage
3. Three to five subcontractors / vendors to manage
4. Six or more subcontractors / vendors to manage

III. Is the vendor well established in the business community with a strong financial background?
1. The vendor is well established and in good financial condition
2. The vendor is well established, but financial condition is unknown
3. The vendor has been established for less than two years
4. The vendor is a startup business with little financial history

IV. What is the vendor's ability to implement the technology?
1. The vendor has successfully completed a number of previous implementations
2. The vendor has successfully completed some previous implementations (1 3)
3. The vendor has limited experience with this technology
4. The vendor has not previously implemented this technology


Financial Opportinity
I. How many components of the IT Strategic Plan does the project support?
1. Project objectives have been clearly documented and can be linked to specific components of the IT Strategic Plan
2. The project direction is consistent with the IT Strategic Plan but the relationship has not been clearly documented
3. Project objectives are not clearly related to the IT Strategic Plan
4. Some or all project objectives may be in conflict with the IT Strategic Plan

II. Is the project required to meet regulatory or legal requirements?
1. Not at all
2. Indirectly
3. Directly at < 50% of units or departments
4. Directly at >50% of units or departments

III. How will project impact utilization of resources?
1. Will pull significant resources of other projects
2. Will pull some resources of other projects
3. Will have a normal impact on resources
4 . Will put currently under-utilized resources to work

IV. To what extent are senior management committed to the project and its outcomes?
1. The consensus of senior management is that the project is not warranted
2. Senior management does not have a consensus regarding the project
3. Senior management agree with the need for the project, but it does not represent their highest priority
4. Senior management is fully committed and have openly endorsed the project

V. Will the project improve skills or provide new experience?
1. Little improvement is expected in existing skills
2. Significant improvement expected in existing skills
3. Little improvement in existing skills but some new skills will be developed
4. Significant improvement in existing and new skills will be developed as well

VI. Will Clinical Outcomes be improved by this project?
1. Not at all
2. Little change
3. Directly at < 50% of units or departments
4. Directly at >50% of units or departments

VII. Will customer service be improved by this project?
1. Not at all
2. Little change
3. Increased customer service to patients, or stakeholders, or physicians
4. Increased customer service to patients, and/or stakeholders, and/or physicians

VIII. Will Delivery of Services be improved by this project?
1. Not at all
2. Little change
3. Directly at < 50% of units or departments
4. Directly at >50% of units or departments

IX. Will productivity be improved by this project?
1. Not at all
2. Little change
3. Increased productivity for stakeholders, or physicians
4. Increased productivity for stakeholders and physicians

X. What are the IT and Technical project coordinators' opinion of the need to win this opportunity?
1. There is no compelling need to win this project
2. The need to win this project is low
3. The need to win this project is moderate
4. This project is vital; we must win it

XI. What is the project's political visibility?
1. Major
2. Significant
3. Moderate
4. Minimal

XII. How do margins compare to annual company goals?
1. Negative margins or breakeven
2. Margins up to 50% of company plan
3. Margins > 50% but < 100% of company plan
4. Margins equal or exceed company plan

XIII. How likely is future business as a result of this project?
1. Project has little or no bearing on future business
2. Future business is possible
3. Future business is likely
4. Future business is assured

XIV. Is there a clearly defined payback for this system?
1. There is neither a payback period nor apparent justification on the basis of patient safety
2. There is a payback period but it is not clearly defined
3. There is not a clearly defined payback but the system is necessary regardless (i.e.for patient safety)
4. There is a clearly defined payback and it is fully justified

XV. What is the estimated revenue for this project?
1. < $500,000
2. > $500,000 and < $2.5 million
3. > $2.5 million and < $5 million
4. > $5 million

XVI. What is the payback time for the project?
1. The payback period has not been quantified
2. The payback period will be greater than 4 years
3. The payback period exceeds 2 years but less than 4 years
4. The payback period is within 2 years

XVII. To what degree have existing expenditures met budgeted amounts?
1. Existing expenditures have consistently exceeded budget amounts or clear budgets have not yet been established
2. Some significant expenditures have exceeded budget amounts with others remaining within budget
3. Most expenditures have been within the budget amounts with a small percentage exceeding budget amounts
4. Existing expenditures have consistently been within budget amounts

XVIII. What is the end-to-end expenditure that this project will require?
1. > $2 Million
2. < $2 Million and > $500,000
3. < $500,000 and > $50,000
4. < $50,000

Here are some more potential sources of risk

1. Use Project Initiation and Requirements documents
2. If you have access to a Risk Assessment list…use it
3. Turn the WBS into a Risk Breakdown Schedule (RBS) and review Project Schedule for:
a. Tasks which your team has no expertise
b. Duration and cost estimates that are aggressive
c. Tasks with numerous or constrained resources
d. Tasks with several predecessors or long durations
4. Brainstorm and talk with the experts
5. Historical Information
a. Project Files (Risk Management Plans from previous projects)
b. Published Information

Risk Options

For negative risks:
• Avoid
• Transfer
• Mitigate
• Accept

For positive risks:
• Exploit
• Share
• Enhance
• Accept

Biz - Good One

Return on Execution (RoX) = Net Gain from Improved Execution / Net Execution Investment

Need to choose right passengers in the Bus (organization), Important thing to this aspect having right people on the right seat. Eg: Having the driver to drive the bus. Passenger knowing where to go and knowing what they are supposed to do in the bus. Aligning Strategy and Execution.

Sports analogy - "the manager can only put players on the field, But the players have to execute" Manager gets to define the strategy, Players will be executing strategy provided the manager and players align together for common cause bounded the organizations objectives, goals, mission and vision for success.

Have X Resources spending Y% of time towards completing Z% of task.

ROI

“Marketing ROI is NOT an increase in market share, click-throughs to your web site or even revenue generated from your marketing communications. ROI is the profits generated over and above the initial investment and expressed as a percent of the investment. There’s a formula, but you really need to understand the nuances of how ROI is calculated in your company because there are multiple ways to interpret concepts like gross margin, net present value or discount rate, just for starters. You need to know your own company’s standards.”

GROSS PROFIT MARGIN

From About: The Gross Profit Margin is a measurement of a company’s manufacturing and distribution efficiency during the production process. The gross profit tells an investor the percentage of revenue/sales left after subtracting the cost of goods sold. A company that boasts a higher gross profit margin than its competitors and industry is more efficient.

From InvestorWords: Gross Profit Margins reveal how much a company earns taking into consideration the costs that it incurs for producing its products and/or services.

It can be expressed in absolute terms:

Gross Profit = Revenue − Cost of Sales

$89,250.00 = $109,250.00 – $20,000

Gross margin is expressed in the form of a percentage:

Gross Margin % = Gross Profit / Revenue

81.69% = $89,250.00 / $109,250.00

Note: Gross Margins of 82% rarely exist. The example does not take into consideration costs that are continually increasing to pay for overhead and marketing, thus lowering Gross Profit Margin.

As example, a company makes 100 widgets in their first year and sells them for $1,000 each. With tax of 9.25% the Revenue or Net Sales is $109,250.00, which is the amount generated after the deduction of returns, allowances for damaged or missing goods, any discounts allowed, freight, and any other expenses (in this case, $0).

The Cost of Sales or Cost of Goods Sold (COGS) is $200 each or $20,000. COGS is the beginning inventory, in this case $0, plus the Cost of Goods Purchased during some period, $20,000, minus the ending inventory, $0, in this case. Gross Profit or Gross Income then is $89,250.00.

RETURN ON INVESTMENT

Now that we have the Gross Margin, we can generate the ROI in the first year (it typically is done on an annual basis).

ROI = ((Revenue – Expenses*) / Investment)

*namely, business, depreciation, interest, and taxes

To get the figure in percentage format, multiply ROI by 100%.

To further the example, when the company went into the widget-making business, they spent $5,000 as their initial investment in setup costs, plus $200 for every widget produced ($20,000), plus $9,250 in taxes. On a sale of 1,000 widgets their ROI is 300%

300% = ($109,250.00 – $34,250) / $25,000

It would be wise to calculate how many widgets they had to sell at pre-tax $1,000 to break even. According to my calculations, when they sold widget #22 they broke even on their current plus future investments.

Furthermore, the investment of $25,000 is likely a loan. If the company borrowed this amount on a 3 year plan at a rate of 20%, by my calculations it would cost them $33,447.24 if compounded annually. Monthly payments, therefore, would be $929.09. As we are just talking about the first year of operations, the first year amount due would be $11,149.08 with the remaining $32,050.92 due in years 2 and 3. Total first year expenses also increase by $2,815.75, which is one third the total interest: $33,447.24 – $25,000 = $8,447.24

Realized Gross Profit (first year): $78,100.92 = $89,250.00 – $11,149.08

Realized Gross Margin (first year): 71.48% = $78,100.92 / $109,250.00

Realized ROI (first year): 289% = ($109,250.00 – $37,065.75) / $25,000

From these results, we can conclude that it would not be a bad investment. However, as more and more details of the reality of costs are added into the equation, profit, margin and ROI will all decrease.

NET PRESENT VALUE

The good business person will then decide if making widgets has the best ROI for the outlay of $25,000 or if some other opportunity – including an investment in financial markets – may yield a higher return. To evaluate this, calculate the Net Present Value, which takes a look at the current value and timing of cash flows, comparing it to the discount rate – the rate of return that could be earned in the financial markets – currently 0.75% as of September 20, 2009. Another name for discount rate is the IRR rate (Internal Rate of Return).

SUMMARY

When we talk about marketing ROI we’re often looking at things like the results of a campaign (purchases, new subscribers, click-throughs), but we have to keep in mind that those results roll up into the real ROI, which calculates return on an overall investment. To do this, we have to calculate three things: Gross Profit, Gross Profit Margin, and ROI.

Gross Profit = Total Revenue minus Cost of Sales or Cost of Goods Sold, which is inventory plus the Cost of Goods Purchased during some period minus the ending inventory.

Gross Profit Margin % = Gross Profit divided by Revenue or Net Sales, which is the amount generated after the deduction of returns, allowances for damaged or missing goods, any discounts allowed, freight, and any other expenses.

ROI = Total Revenue minus Total Expenses, divided by the Total Investment. The result can be calculated across different scenarios and it can then be decided where the investment can be best spent, taking into consider the Net Present Value of the differing cash flows that are created.

Quick Agile Knowledge

Today’s typical Agile process, no matter what name you call it, takes the best from the buffet of Agile practices to create a typical process where:

1. Project needs or requirements are expressed in user stories placed in a backlog, and ideally written by Product owners (in Scrum), or customers (in XP) in collaboration with the development team. (Sometimes they magically appear.)
2. Developers give high-level estimates saying how long user stories will take to complete.
3. Product owners arrange user stories into incremental releases that take typically 6 weeks to 6 months.
4. Product owners choose the next stories, highest value first, for each development time-box. The stories chosen need to “fit” into the time-box based on how quickly the team can produce software.
5. At the end of each development time-box the team should have incrementally built some of the product. The team (proudly) demonstrates the finished product to product owners and other stakeholders.
6. The team adds up the development estimates for the user stories completed during the time-box. This is the velocity (from XP) that’ll be used to estimate the amount that can be completed in the next time-box.
7. The team holds a retrospective to evaluate how well they’ve done and what changes could be made to the process to allow things to go better, then the next time-boxed development cycle is planned.
8. Time-boxed development continues through to release — which is a short way of saying “rinse and repeat.”

There’s more common practices, such as daily standup meetings to synchronize the team, and burn-down charts to show development progress, but that’s enough to make my point: Today’s Agile process is a mash-up of a variety of good ideas from a variety of sources.

Winning and Losing

Matt Damon (as a card player in the movie Rounders) said it best: You can’t lose what you don’t put in the middle. But you can’t win much either. So, I hope that life presents you with many opportunities; that you have the wisdom to balance the risks and rewards, and that you have the courage to pursue great challenges.

Excellent demo of using Hibernate

Excellent demo of using Hibernate

Excellent Article about Methodology

Excellent Article about Methodology

Increase the Effectiveness of Learning

From : http://psychology.about.com/od/educationalpsychology/tp/effective-learning.htm


How to Become a More Effective Learner
Tips from Psychology to Improve Learning Effectiveness & Efficiency

By Kendra Van Wagner, About.com
See More About:

* memory
* learning
* educational psychology

I'm always interested in finding new ways to learn better and faster. As a graduate student who is also a full-time science writer, the amount of time I have to spend learning new things is limited. It's important to get the most educational value out of my time as possible. However, retention, recall and transfer are also critical. I need to be able to accurately remember the information I learn, recall it at a later time and utilize it effectively in a wide variety of situations.

1. Memory Improvement Basics
I've written before about some of the best ways to improve memory. Basic tips such as improving focus, avoiding cram sessions and structuring your study time are a good place to start, but there are even more lessons from psychology that can dramatically improve your learning efficiency.

2. Keep Learning (and Practicing) New Things
"Learning is good for your brain. "Learning and practicing new skills helps your brain retain new information. Image by Mysid.

One sure-fire way to become a more effective learner is to simply keep learning. A 2004 Nature article reported that people who learned how to juggle increased the amount of gray matter in their occipital lobes, the area of the brain is associated with visual memory.1 When these individuals stopped practicing their new skill, this gray matter vanished.

So if you're learning a new language, it is important to keep practicing the language in order to maintain the gains you have achieved. This "use-it-or-lose-it" phenomenon involves a brain process known as "pruning." Certain pathways in the brain are maintained, while other are eliminated. If you want the new information you just learned to stay put, keep practicing and rehearsing it.

3. Learn in Multiple Ways
Focus on learning in more than one way. Instead of just listening to a podcast, which involves auditory learning, find a way to rehearse the information both verbally and visually. This might involve describing what you learned to a friend, taking notes or drawing a mind map. By learning in more than one way, you’re further cementing the knowledge in your mind. According to Judy Willis, “The more regions of the brain that store data about a subject, the more interconnection there is. This redundancy means students will have more opportunities to pull up all of those related bits of data from their multiple storage areas in response to a single cue. This cross-referencing of data means we have learned, rather than just memorized.”2

4. Teach What You've Learned to Another Person
""Teaching can improve your learning. ©René Mansi/iStockPhoto

Educators have long noted that one of the best ways to learn something is to teach it to someone else. Remember your seventh-grade presentation on Costa Rica? By teaching to the rest of the class, your teacher hoped you would gain even more from the assignment. You can apply the same principle today by sharing your newly learned skills and knowledge with others.

Start by translating the information into your own words. This process alone helps solidify new knowledge in your brain. Next, find some way to share what you’ve learned. Some ideas include writing a blog post, creating a podcast or participating in a group discussion.

5. Utilize Previous Learning to Promote New Learning
Another great way to become a more effective learner is to use relational learning, which involves relating new information to things that you already know. For example, if you are learning about Romeo and Juliet, you might associate what you learn about the play with prior knowledge you have about Shakespeare, the historical period in which the author lived and other relevant information.

6. Gain Practical Experience
For many of us, learning typically involves reading textbooks, attending lectures or doing research in the library or on the Web. While seeing information and then writing it down is important, actually putting new knowledge and skills into practice can be one of the best ways to improve learning. If you are trying to acquire a new skill or ability, focus on gaining practical experience. If it is a sport or athletic skill, perform the activity on a regular basis. If you are learning a new language, practice speaking with another person and surround yourself with immersive experiences.

7. Look Up Answers Rather Than Struggle to Remember
Of course, learning isn’t a perfect process. Sometimes, we forget the details of things that we have already learned. If you find yourself struggling to recall some tidbit of information, research suggests that you are better offer simply looking up the correct answer. One study found that the longer you spend trying to remember the answer, the more likely you will be to forget the answer again in the future. Why? Because these attempts to recall previously learned information actually results in learning the "error state" instead of the correct response.

8. Understand How You Learn Best
Another great strategy for improving your learning efficiency is to recognize your learning habits and styles. There are a number of different theories about learning styles, which can all help you gain a better understanding of how you learn best. Gardner’s theory of multiple intelligences describes eight different types of intelligence that can help reveal your individual strengths. Looking at Carl Jung’s learning style dimensions can also help you better see which learning strategies might work best for you.

9. Use Testing to Boost Learning
"Testing can be more effective than studying."Testing can be more beneficial than studying alone. Image by Clinton Cardozo.
While it may seem that spending more time studying is one of the best ways to maximize learning, research has demonstrated that taking tests actually helps you better remember what you've learned, even if it wasn't covered on the test.3 The study revealed that students who studied and were then tested had better long-term recall of the materials, even on information that was not covered by the tests. Students who had extra time to study but were not tested had significantly lower recall of the materials.

10. Stop Multitasking
"Multitasking can hurt learning effectiveness"Multitasking can hurt learning effectiveness. ©Paul Kline/iStockPhoto
For many years, it was thought that people who multitask, or perform more than one activity at once, had an edge over those who did not. However, research now suggests that multitasking can actually make learning less effective. In the study, participants lost significant amounts of time as they switched between multiple tasks and lost even more time as the tasks became increasingly complex.4 By switching from one activity to another, you will learn more slowly, become less efficient and make more errors. How can you avoid the dangers of multitasking? Start by focusing your attention on the task at hand and continue working for a predetermined amount of time.
11. References

1 Draganski, B., Gaser, C., Busch, V., & Schuierer, G. (2004). Neuroplasticity: Changes in grey matter induced by training. Nature, 427(22), 311-312.

2 Willis, J. (2008). Brain-based teaching strategies for improving students' memory, learning, and test-taking success.(Review of Research). Childhood Education, 83(5), 31-316.

3 Chan, J.C., McDermott, K.B., & Roediger, H.L. (2007). Retrieval-induced facilitation. Journal of Experimental Psychology: General, 135(4), 553-571.

4 Rubinstein, Joshua S.; Meyer, David E.; Evans, Jeffrey E. Journal of Experimental Psychology: Human Perception and Performance, 27(4), 763-797.

cool Q

Import the column as text file to access and execute - SELECT table.col, count( column) FROM Table group by col;

What happened at Leh

What Happened at Lehman, in 30 Seconds or Less

A good posting from :
http://nymag.com/daily/intel/2008/09/what_happened_at_lehman_in_30.html

Someone has written a "30-second version" of what happened to cause the mortgage crisis on Google finance, and it's probably the most lucid one we've seen so far. Although it might actually be more like a 40-second version, since those mortgage-backed securities are a bitch to get your head around no matter how you slice 'em.

People went to traditional banks and mortgage brokers and bought mortgages. All of these mortgages carry different amounts (e.g. $100,000 mortgage vs. a $500,000 mortgage) and different risk levels. The ones that are more likely to default have a higher interest rate, so the bank stands to gain more money...but at a greater risk of the home owner defaulting on the mortgage.

The problem with this is it is very difficult to balance your risk-reward ratio. So they created an investment vehicle called a mortgage-backed security (MBS). This is refered to as a "derivative" because it is based off of the mortgage. The way it works is the banks chopped up all these different mortgages into different securities that were worth different amounts and different risk levels. They then sold these to other banks and investments firms. The firms who bought these MBS then received a payment based off of the mortgages. For the banks selling MBS, it helped them pool risk and generate capital, and for the firms who bought the MBS, it provided a source of cash flow with what was thought to be a very safe,secure underlying commodity: real estate.

Since real estate was so "safe," these banks used huge amounts of leverage (borrowed money to buy the securities) because they didn't think they were that risky. Some firms, like Lehman, were leveraged 30:1, meaning that for every $30 they borrowed, they had $1 of underlying assets. That would be like you making $1000 a year but taking out a loan of $30,000.

While all this is going on, people are buying up adjustable interest rate mortgages (ARMs). They offer a cheap introductory rate, but then skyrocket. So all of a sudden, all these people discovered they couldn't make their monthly payments. The default rate shot through the roof. The firms that had purchased MBS did so based on certain calculations of default. In other words, X number of people could default on their mortgages, but they could still make a profit and
have a positive cash-flow. However, when the default rate shot up, this threw all of their calculations off.

Now the firms faced a real problem. They had HUGE amounts of debt on their balance sheets, and the assets that were supposed to balance that debt were becoming worth less and less because of the rising default rate and the drop in housing prices. These are the "write-downs" that you hear about. The firms had to pay interest on that debt, but they did not have the corresponding cash flow to be able to pay the debt. Lehman, for example, had $5.4B of debt obligations last quarter, but only had $2.3B in income.

When you can't pay your debt obligations, that's called being insolvent. Many people think that bankruptcy is caused by having more liabilities than assets, but that's not true. It's caused when you can't make good on your debts, so the repo man comes and claims your assets in order to make up for it. When that happens, you have to file for bankruptcy in order to make sure that people get paid in the correct order because otherwise different creditors are going to be suing you to make sure they get what you owe them.

So that's where we are now with Lehman. They couldn't pay their debts, so they had to file for bankruptcy.

Notes

Be SMART, CONSIDERATE, PROMPT, HONEST, HELPFUL, KIND, CREATIVE, DETERMINED, PATIENT

Management by Objectives introduced the SMART method for checking the validity of the objectives, which should be
'SMART':
- Specific
- Measurable
- Achievable
- Realistic
- Time-related.

MBO by Peter Drucker:
What is this theory about?
MBO (Management By Objectives) relies on the defining of objectives for each employee and then to compare and to direct their performance against the objectives which have been set. It aims to increase the performance of the organization by matching organizational goals with the objectives of subordinates throughout the organization. Ideally, employees receive strong input to identify their objectives, time lines for completion, etc. MBO includes continuous tracking of the processes and providing feedback to reach the objectives.

Principles of Management by Objectives:
- Cascading of organizational goals and objectives,
- Specific objectives for each member,
- Participative decision making,
- Explicit time period, and
- Performance evaluation and provide feedback.

Successful Leader

To be a Successful Leader, You need to make other people Successful

Do Whay You Say You Will Do

Keep the Lines of Communication Open

If you treat people with Kindness they perform much better

Excerpt from "Leading with Kindness"

GetHuman

Get to Human from Phone Numbers

ADM - CMDB

ADM - Application Dependency Mapping - Remote Deployment, Hot Deployment, Application/ Site monitoring, Product/Project Launch Process, Enterprise Level Application Management

CMDB - Configuration Management Database

ITIL - IT Infrastructure Libraries

Configuraion Files, Device Level Management, Port Allocation Tables, Analyze and determine Application Dependencies

Security Aspects - Network, Corporate IAM (Identity Access Management), VPN, SecureID, Network Deployment

Network Management Tool to take care of certain level of business process and execute rule/state based transition.

Connect the dots between NMS, ADM, CMDB, ITIL, Security

Randy Pausch

In Memoriam:
Randy Pausch, Innovative Computer Scientist at Carnegie Mellon,

Launched Education Initiatives, Gained Worldwide Acclaim for Last Lecture
PITTSBURGH—Randy Pausch, renowned computer science professor at Carnegie Mellon University, died July 25 of complications from pancreatic cancer. He was 47.

Celebrated in his field for co-founding the pioneering Entertainment Technology Center and for creating the innovative educational software tool known as "Alice," Pausch earned his greatest worldwide fame for his inspirational "Last Lecture."

That life-affirming lecture, a call to his students and colleagues to go on without him and do great things, was delivered at Carnegie Mellon on Sept. 18, 2007, a few weeks after Pausch learned he had just months to live. Titled "Really Achieving Your Childhood Dreams," the humorous and heartfelt talk was videotaped, and unexpectedly spread around the world via the Internet. Tens of millions of people have since viewed video footage of it.

Pausch, who had regularly won awards in the field of computer science, spent the final months of his life being lauded in arenas far beyond his specialty. ABC News declared him one of its three "Persons of the Year" for 2007. TIME magazine named him to its list of the 100 most influential people in the world. On thousands of Web sites, people wrote essays about what they had learned from him. His book based on the lecture became a #1 bestseller internationally, translated into 30 languages

Key Capabilties for mitigating Competency Trap

Excerpt from the meeting at BQF Innovation Unit to discuss issues of Competency Traps

The session was led by Richard Granger of Arthur D Little. He presented a comprehensive review of the topic and then facilitated a workshop where delegates assessed their organisational competence in 7 key areas. Competency traps are skills, attributes and things we are proud of, that constrain our thinking. They break down into a Vision trap, a Routinisation trap and Technology traps. Richard advised that the best way to combat these hazards is to open the organisation up to external stimuli. This led into a discussion of many aspects of open innovation and we reviewed what P&G, Rolls-Royce and Philips Research were doing in these areas.

Seven key management capabilities were identified:

1. Innovation Sourcing Strategy
2. Ideas Management
3. Business Intelligence
4. Relationship Management
5. Project Management
6. Competence Management
7. Innovation Culture


By ~ Paul Sloane

Radically Simple IT - HBR

Radically Simple IT - HBR

By designing and deploying enterprise systems in a different way, Japan’s Shinsei Bank turned IT from a constraint into a launchpad for growth.

by David M. Upton and Bradley R. Staats

Enterprise IT projects—both custom and packaged “one size fits most” systems—continue to be a major headache for business leaders. The fundamental problem with these systems is that for the most part, they’re constructed using what programmer and open source champion Eric Raymond dubbed a cathedral approach. Like the great edifices that Europeans erected in the Middle Ages, enterprise IT projects are costly, take a great deal of time, and deliver value only when the project is completed. In the end, they yield systems that are inflexible and cement companies into functioning the way their businesses worked several years ago, when the project started. Despite recent improvements in the flexibility of packaged software, companies often find it exorbitantly expensive and difficult to modify their enterprise systems in order to exploit new business opportunities.

Instead of building systems that are legacy from the day they are turned on, managers can and should develop systems that can be improved—rapidly and continuously—well after they’ve gone live. Over the past decade, we’ve studied the design and implementation of enterprise IT systems and assisted numerous firms with the process. Through our work, we have identified an approach that not only reduces a company’s costs but supports the growth of existing businesses and the launch of new ones. We call it a “path based” approach, because rather than attempting to define all of the specifications for a system before the project is launched, companies focus on providing a path for the system to be developed over time. The approach’s premises are that it is difficult and costly to map out all requirements before a project starts because people often cannot specify everything they’ll need beforehand. Also, unanticipated needs almost always arise once a system is in operation. And persuading people to use and “own” the system after it is up and running is much easier said than done.

In our research, we discovered a standout among the companies applying the path-based method: Japan’s Shinsei Bank. It succeeded in developing and deploying an entirely new enterprise system in one year at a cost of $55 million: That’s one-quarter of the time and about 10% of the cost of installing a traditional packaged system. The new system not only served as a low-cost, efficient platform for running the existing business but also was flexible enough to support the company’s growth into new areas, including retail banking, consumer finance, and a joint venture to sell Indian mutual funds in Japan.

The path-based principles that Shinsei applied in designing, building, and rolling out the system—forging together, not just aligning, business and IT strategies; employing the simplest possible technology; making the system truly modular; letting the system sell itself to users; and enabling users to influence future improvements—are a model for other companies. Some of these principles are variations on old themes while others turn the conventional wisdom on its head.
Born of Necessity

Shinsei came into being when Long-Term Credit Bank, founded by the Japanese government to assist in the rebuilding of the country’s industries after World War II, went bust in 1998 with nearly $40 billion in nonperforming loans. The firm was nationalized, then sold in 2000 to Ripplewood Holdings, a U.S. private equity fund, and renamed Shinsei, which means “new birth.” Ripplewood executives coaxed Masamoto Yashiro, the former chairman of Citibank Japan, out of retirement to lead Shinsei. In addition to deciding to revamp existing commercial-banking operations, Yashiro formulated a plan for revolutionizing retail banking in Japan by offering a value proposition that was unique in the country at that time: high-quality products and services provided on a convenient, easy-to-use, low-cost basis. The strategy called for Shinsei to offer services that were then uncommon in Japan, including ATMs available 24/7 free of charge, internet banking, online foreign-exchange trading, online bilingual banking, and quick service supported by real-time database reconciliation (meaning customers’ accounts were updated immediately after each transaction).

Yashiro felt that the bank needed to move quickly to seize the opportunity in retail banking. However, the firm’s existing IT systems were antiquated and could not even support the bank’s existing corporate business adequately. To address these issues, Yashiro hired his former colleague Dhananjaya “Jay” Dvivedi, who had led IT operations at Citibank Japan, to be chief information officer. Upon taking the job, Dvivedi quickly surrounded himself with a talented core team, most of whom had worked for him previously. Since the recovering bank had limited investment funds, Yashiro gave Dvivedi the mandate to revolutionize IT but with the understanding that his team needed to do it “fast” and “cheap.” Recognizing that they could not fully know what the retail operation would need, the two men agreed that the goal should be to build a system that could scale with growth and adapt to new opportunities that the dynamic business would create.

The conventional choices for building a major enterprise system were two: the “big bang” approach of replacing the current system with an entirely new system and processes all at once or the incremental method of improving or replacing the existing system one small piece at a time. Dvivedi and his team were leery of taking the big bang route, believing it was too risky given the bank’s cash constraints and knowing all too well the problems endemic to such projects. The incremental course, however, which would probably take three to five years, would be far too slow. So they decided to blaze a third path. They would put into place a new, modular infrastructure that at first would function in parallel with but eventually would supersede the current infrastructure. According to traditional IT thinking, this was madness. Much bridging software would have to be developed to span the old and the new, which would require an enormous effort.

But Dvivedi knew from his prior work and his conversations with other CIOs that technical problems were almost never the reason that new IT systems flopped. Human problems were. People typically resist adopting new systems, often because the cost (the effort) outweighs the benefits. To address this, Dvivedi used simple but innovative technology solutions to avoid the wrenching go-live experience. For example, by mimicking the old system’s look and feel at least for a while, Dvivedi and his team were able to speed adoption of the new system.

Mastering the Management System - HBR

Mastering the Management System - from HBR

Successful strategy execution has two basic rules: understand the management cycle that links strategy and operations, and know what tools to apply at each stage of the cycle.

by Robert S. Kaplan and David P. Norton

Not long after its successful IPO, the Conner Corporation (not its real name) began to lose its way. The company’s senior executives continued their practice of holding monthly one-day management meetings, but their focus drifted.

The meetings’ agenda called for a discussion of operational issues in the morning and strategic issues in the afternoon. But with the company under pressure to meet quarterly targets, operational items had started to crowd strategy out of the agenda. Inevitably, the review of actual monthly and forecast quarterly financial performance revealed revenues to be lower, and expenses to be higher, than targeted. The worried managers spent hours discussing how to close the gap through pricing initiatives, capacity downsizing, SG&A staff cuts, and sales campaigns. One executive noted, “We have no time for strategy. If we miss our quarterly numbers, we might cease to exist. For us, the long term is the short term.”

Like Conner, all too many companies—including some well-established public corporations—have learned how Gresham’s Law applies to their management meetings: Discussions about bad operations inevitably drive out discussions about good strategy implementation. When companies fall into this trap, they soon find themselves limping along, making or closely missing their numbers each quarter but never examining how to modify their strategy to generate better growth opportunities or how to break the pattern of short-term financial shortfalls. Analysts, investors, and board members start to question the imagination and commitment of the companies’ management.

In our experience, however, breakdowns in a company’s management system, not managers’ lack of ability or effort, are what cause a company’s underperformance. By management system, we’re referring to the integrated set of processes and tools that a company uses to develop its strategy, translate it into operational actions, and monitor and improve the effectiveness of both. The failure to balance the tensions between strategy and operations is pervasive: Various studies done in the past 25 years indicate that 60% to 80% of companies fall short of the success predicted from their new strategies.

By creating a closed-loop management system, companies can avoid such shortfalls. (See the exhibit “How the Closed-Loop Management System Links Strategy and Operations.”) The loop comprises five stages, beginning with strategy development, which involves applying tools, processes, and concepts such as mission, vision, and value statements; SWOT analysis; shareholder value management; competitive positioning; and core competencies to formulate a strategy statement. That statement is then translated into specific objectives and initiatives, using other tools and processes, including strategy maps and balanced scorecards. Strategy implementation, in turn, links strategy to operations with a third set of tools and processes, including quality and process management, reengineering, process dashboards, rolling forecasts, activity-based costing, resource capacity planning, and dynamic budgeting. As implementation progresses, managers continually review internal operational data and external data on competitors and the business environment. Finally, managers periodically assess the strategy, updating it when they learn that the assumptions underlying it are obsolete or faulty, which starts another loop around the system.
Sidebar IconHow the Closed-Loop Management System Links Strategy and Operations

A system such as this must be handled carefully. Often the breakdown occurs right at the beginning, with companies formulating grand strategies that they then fail to translate into goals and targets that their middle and lower managers understand and strive to achieve. Even when companies do formalize their strategic objectives, many still struggle because they do not link these objectives to tools that support the operational improvement processes that ultimately must deliver on the strategy’s objectives. Or, like Conner, they decide to mix discussions of operations and strategy at the same meeting, causing a breakdown in the strategic-learning feedback loop.

In the following pages we draw upon our extensive research and experience advising companies, as well as nonprofit and public sector entities, to describe the design and implementation of a system for strategic planning, operational execution, and feedback and learning. We present a range of tools that managers can apply at the different stages, most developed by other management experts and some of our own design. (See “A Management System Tool Kit” for further reading on the tools discussed.) We will show how these can all be integrated in a system that links the management of strategy and operations.
Sidebar IconA Management System Tool Kit
Stage 1: Develop the Strategy

The management cycle begins with articulating the company’s strategy. This usually takes place at an annual offsite meeting during which the management team either incrementally improves an existing strategy or, on occasion, introduces an entirely new one. (Our experience suggests that strategies generally have three to five years of useful life.) Developing an entirely new strategy may take two sets of meetings, each lasting two to three days. At the first, executives should reexamine the company’s fundamental business assumptions and its competitive environment. After some homework and research, the executives will hold the second set of meetings and decide on the new strategy. Typically, the CEO, other corporate officers, heads of business and regional units, and senior functional staff attend these strategy sessions. The agenda should explore the following questions:

The Experience Trap - HBS INSEAD

The Experience Trap - HBS INSEAD

As projects get more complicated, managers stop learning from their experience. It is important to understand how that happens and how to change it.

by Kishore Sengupta, Tarek K. Abdel-Hamid, and Luk N. Van Wassenhove

If you were looking for an experienced manager to head up a software development team, Alex would be at the top of your short list. A senior manager, Alex has spent most of his career running software projects. His first responsibility was developing scientific software for NASA, and since then, he has overseen ever more complex projects for commercial enterprises and government agencies.

Alex was typical of the several hundred project managers who participated in our research initiative on experience-based learning in complex environments. We invited him to test his skills by playing a computer-based game that entails managing a simulated software project from start to finish—making the plans, monitoring and guiding progress, and observing the consequences. We set goals for him: finish on time and within budget, and obtain the highest possible quality (as measured by the number of defects remaining).

Alex’s decisions and outcomes were representative of the group as a whole. He started with a small team of four engineers and focused mostly on development work. That tactic paid off in the short run. The team’s productivity was high and development progressed quickly. However, when the size of the project grew beyond initial estimates, problems cropped up. Because Alex still chose to keep the team small, the engineers had to work harder to stay on track. Consequently, they made many mistakes and experienced burnout and attrition. Alex then tried to hire more people, but this took time, as did assimilating the new hires. The project soon fell behind schedule, and at that point Alex’s lack of attention to quality assurance in the early phases started to show up in snowballing numbers of software errors. Fixing them required more time and attention. When the project was finally completed, it was late, over budget, and riddled with defects.

After the game, we asked Alex to reflect on the simulation. Did the project’s growth take him by surprise? Was he shocked that the number of defects was so high or that hiring became difficult to manage? Alex—like most of his fellow participants—replied that such surprises and shocks have, unfortunately, become regular occurrences in most of the projects in which he’s been involved.

Quality and personnel headaches are not what most companies expect when they put seasoned veterans like Alex in charge of important projects. At this stage of their careers, they should know how to efficiently address problems—if not prevent them altogether. What we discovered in our experiments, however, was that managers with experience did not produce high-caliber outcomes. In our research, we used the simulation game to examine the decision processes of managers in a variety of contexts. Our results strongly suggest that there was something wrong with the way Alex and the other project managers learned from their experiences during the game. They did not appear to take into account the consequences of their previous decisions as they made new decisions, and they didn’t change their approach when their actions produced poor results.

Our debriefings indicated that the challenges presented in the game were familiar to the participants. We asked them to rate the extent to which the game replicated their experiences on real-life projects on a scale of 1 to 5, where 5 meant “completely.” The average score was 4.32, suggesting that our experiments did accurately reflect the realities of software projects. So, though the managers had encountered similar situations on their jobs in the past, they still struggled with them in the simulations. We came to the conclusion that they had not really learned from their real-life project work, either.

In the following pages we’ll identify three likely causes for this apparent breakdown in learning, and we’ll propose a number of steps that organizations can take to enable learning to kick in again.
Why Learning Breaks Down

When anyone makes a decision, he or she draws on a preexisting stock of knowledge called a mental model. It consists largely of assumptions about cause-and-effect relationships in the environment. As people observe what happens as a result of their decisions, they learn new facts and make new discoveries about environmental relationships. Discoveries that people feel can be generalized to other situations are fed back, or “appropriated,” into their mental models. On the face of it, the process seems quite scientific—people form a hypothesis about a relationship between a cause and an effect, act accordingly, and then interpret the results from their actions to confirm or revise the hypothesis. The problem is that the approach seems to be effective only in relatively simple environments, where cause-and-effect relationships are straightforward and easily discovered. In more complex environments, such as software projects, the learning cycle frequently breaks down. In the experiments we carried out with our study participants, we identified three types of real-world complications that were associated with the cycle’s breakdown.

Manage Your Energy, Not Your Time

Manage Your Energy, Not Your Time - From HBR

The science of stamina has advanced to the point where individuals, teams, and whole organizations can, with some straightforward interventions, significantly increase their capacity to get things done.

by Tony Schwartz and Catherine McCarthy

Steve Wanner is a highly respected 37-year-old partner at Ernst & Young, married with four young children. When we met him a year ago, he was working 12- to 14-hour days, felt perpetually exhausted, and found it difficult to fully engage with his family in the evenings, which left him feeling guilty and dissatisfied. He slept poorly, made no time to exercise, and seldom ate healthy meals, instead grabbing a bite to eat on the run or while working at his desk.

Wanner’s experience is not uncommon. Most of us respond to rising demands in the workplace by putting in longer hours, which inevitably take a toll on us physically, mentally, and emotionally. That leads to declining levels of engagement, increasing levels of distraction, high turnover rates, and soaring medical costs among employees. We at the Energy Project have worked with thousands of leaders and managers in the course of doing consulting and coaching at large organizations during the past five years. With remarkable consistency, these executives tell us they’re pushing themselves harder than ever to keep up and increasingly feel they are at a breaking point.

The core problem with working longer hours is that time is a finite resource. Energy is a different story. Defined in physics as the capacity to work, energy comes from four main wellsprings in human beings: the body, emotions, mind, and spirit. In each, energy can be systematically expanded and regularly renewed by establishing specific rituals—behaviors that are intentionally practiced and precisely scheduled, with the goal of making them unconscious and automatic as quickly as possible.

To effectively reenergize their workforces, organizations need to shift their emphasis from getting more out of people to investing more in them, so they are motivated—and able—to bring more of themselves to work every day. To recharge themselves, individuals need to recognize the costs of energy-depleting behaviors and then take responsibility for changing them, regardless of the circumstances they’re facing.

The rituals and behaviors Wanner established to better manage his energy transformed his life. He set an earlier bedtime and gave up drinking, which had disrupted his sleep. As a consequence, when he woke up he felt more rested and more motivated to exercise, which he now does almost every morning. In less than two months he lost 15 pounds. After working out he now sits down with his family for breakfast. Wanner still puts in long hours on the job, but he renews himself regularly along the way. He leaves his desk for lunch and usually takes a morning and an afternoon walk outside. When he arrives at home in the evening, he’s more relaxed and better able to connect with his wife and children.

Establishing simple rituals like these can lead to striking results across organizations. At Wachovia Bank, we took a group of employees through a pilot energy management program and then measured their performance against that of a control group. The participants outperformed the controls on a series of financial metrics, such as the value of loans they generated. They also reported substantial improvements in their customer relationships, their engagement with work, and their personal satisfaction. In this article, we’ll describe the Wachovia study in a little more detail. Then we’ll explain what executives and managers can do to increase and regularly renew work capacity—the approach used by the Energy Project, which builds on, deepens, and extends several core concepts developed byTony’s former partner Jim Loehr in his seminal work with athletes.
Linking Capacity and Performance at Wachovia

Most large organizations invest in developing employees’ skills, knowledge, and competence. Very few help build and sustain their capacity—their energy—which is typically taken for granted. In fact, greater capacity makes it possible to get more done in less time at a higher level of engagement and with more sustainability. Our experience at Wachovia bore this out.

Competency Trap : Stanford GSB

The Agony of Victory
Why a company's greatest peril is often its own success.
Business 2.0 Magazine
By Jeffrey Pfeffer, Business 2.0 Magazine columnist

(Business 2.0 Magazine) -- While dissecting the Democratic party's landslide victory in November, many pundits have criticized the Republicans for making strategic and operational mistakes leading up to the midterm elections.

There were plenty of both, I'm sure, but what I see when I look at what happened last fall is one of the most intractable problems to beset corporations, nonprofits, and even pro ball clubs: falling prey to what's known to management scholars as a "competency trap."

The concept is deceptively simple. Organizations try things. If what they do succeeds, they "learn" that what they have done breeds success. So they persist, becoming ever more focused in what they do, and ever more specialized in the skills they acquire.


How to succeed in 2007

But two things invariably happen to undermine success. Competitors soon learn how to do the same thing, and conditions change, so that what worked in the past no longer applies. Companies have trouble adapting because they often build competencies that don't advance new products, markets, or strategies.

Hence the phrase "competency trap."

Chrysler, for instance, virtually invented the minivan during the 1980s and made a fortune from it. Then came SUVs and hybrids and more recently the spike in gasoline prices.

America's car-buying tastes changed, but Chrysler's factories had been configured to produce a particular style of car, and innovation had, of necessity, been narrowly focused on improvements in minivans. In the meantime, other car companies got into minivans, increasing the competition.

Under pressure, Chrysler (Charts) merged with Daimler-Benz.

There are plenty of instances of competency traps playing out in professional sports. Bill Walsh is credited with inventing the "West Coast offense" made famous by Joe Montana and the San Francisco 49ers of the 1980s and '90s. But when defenses figured out how to respond, and imitation by other teams eroded the advantage of this particular strategy, the 49ers lost their dominance.

Avoiding getting trapped by our own skill and success is a difficult, almost impossible, task. That's because one common recommendation - to keep innovating and doing things differently - has its own set of problems.

It's costly, and it can be just as prone to failure. But three strategies can help avoid competency traps.

The first is to avoid excessive specialization. Toyota has never put all its eggs in one basket - it makes high-quality trucks, minivans, even hybrids. By building a broad range of competencies and knowledge, Toyota can react quickly to changes in market conditions.

The second is to develop peripheral vision, which entails following Andy Grove's advice that "only the paranoid survive." Markets don't change all at once. Pay attention to the facts, not to what you want to believe.

Finally, understanding that a company's greatest strength can become its greatest weakness when circumstances change can help build a mind-set of continuous learning and vigilance.

No company, team, or political party can be equally good at everything. But understanding how success breeds its own problems, and acting on that knowledge, can help mitigate the problem.

Business 2.0 columnist Jeffrey Pfeffer is the Thomas D. Dee II Professor of Organizational Behavior at Stanford University's Graduate School of Business.

Great words of Bharathiar......

"Anna Sathiram Aayiram Naatal, Aalayam Padhinaayiram Naatal,
Andam yaavilum Punniyam Kodi
Aangor Yaezhaikku Yezhutharivithal"

Consulting Books and Movies

List of favorite books on consulting :

Thinkertoys (Michalko)
Million Dollar Consulting (Weiss)
Leading Change (Kotter)
The Mckinsey Mind (Rasiel)
Shenson on Consulting (Shenson)
The Knowledge Society (Drucker)
The Trusted Advisor (Maister)
The Consultant's Calling (Bellman)
The Achievers (Bell)
How to Become a Successful Consultant in Your Own Field (Bermont)
How to build a successful consulting practice (Phillips)
The Emyth Revisited: Why Small Businesses Don't Work and What To Do About It (Gerber)
Managing the Professional Services Firm (Maister)

Million Dollar Consulting got the most mentions as the complete book consultants use both to start their practice as well as to serve as an ongoing reference book.


How about using some classic movies as the basis of discussion? Some movies have rich characters, plot and storylines that would make for fertile discussion among members of a management team. Here are a few:

Twelve Angry Men (1957) is a story of a jury deciding an apparent open and shut murder case. The character development and evolving story line reflects common interactions in management team negotiations.

The Caine Mutiny (1954) addresses weakness of command, ethical dilemmas, communication between ranks, and executive decisionmaking. And you though running a company was easy?

The Godfather (1972) is all about what is business and what is personal, transfer of control, and about the impact of traditions on operation of an enterprise.

12 O'Clock High (1949) is a look into leadership, betrayal, morale, discipline, and perseverance under duress. Strip away the war setting and you will find many elements of how teams behave under stressful settings and how they cope.

The Office - Not a movie but a weekly TV show with fertile representation of all too familiar personalities in many business settings. A smorgasbord of how not to manage.

Have managers watch these movies for discussion and comparison to their current individual and group behavior. Better yet, have the team watch them together on your next management retreat and discuss merits of the characters and team behavior.

Indian Prof at KSM and HBS

Ranjay Gulati is a Visiting Professor at Harvard Business School and the Michael L. Nemmers Distinguished Professor of Strategy and Organizations at the Kellogg School of Management, Northwestern University. He is an expert on strategic and organizational issues in firms. His work has focused on intra and inter-firm partnerships with a focus on the patterns of network of ties that emerge over time. He has looked at a number of issues surrounding interfirm alliances including who has ties with whom, governance of those exchange relationships, and determinants of performance. His most recent book is Managing Network Resources: Alliances, Affiliations, and other Relational Assets. He is the past-President of the Business Policy and Strategy Division at the Academy of Management and has served as an advisor to start-ups and major corporations. He holds a Ph.D. from Harvard Business School, a masters degree in Management from M.I.T.'s Sloan School of Management, and two bachelor's degrees, in Computer Science and Economics, from Washington State University and St. Stephens College, New Delhi, respectively. He has been a Harvard MacArthur Fellow and a Sloan Foundation Fellow.

Consulting
Ranjay Gulati is a recognized specialist on strategic and organizational issues in firms and has also done significant work on the creation and management of intra and inter-firm partnerships, including strategic alliances and mergers. He has also focused on issues related to achieving short term and long term organic growth as well as through mergers, acquisitions, and alliances. Most recently, he has worked with a number of firms on transitioning from product to market/solution centric models. He has consulted with wide array of firms on these topics on both short and long term assignments.

Executive Lectures
Ranjay has received several awards for his outstanding teaching. In 1998-1999 he received the Chairs' Core Teaching Award at the Kellogg School of Management and in 2003 was elected the Professor of the year by the executive MBA students in the Kellogg-HKUST program. Through executive seminars and open lectures, Ranjay creates a forum for the development and implementation of business strategies for the challenging market conditions we face today. Each lecture is customized to fit the audience and their circumstances. Some of the topics that Ranjay regularly lectures on include:

Building Market Driven Organizations

Spurred by visions of the future and haunted by intense competition, companies are rushing to realize the goal of creating a customer-focused organization. Despite the increasing need for a customer-focused strategy in a competitive business environment there are few paradigms of how companies can change their strategy and organization to become customer focused. This session presents a roadmap of the stages through which companies evolve as they embark on this journey towards greater market focus. Through a series of cases about firms in a range of industries that have successfully embarked on some of these changes, we will develop a comprehensive blueprint for the market driven organization. Topics will include:

• What is a market driven strategy?
• Is a market driven strategy right for you?
• Obstacles to formulating and implementing a market driven strategy
• The road to building a market driven organization

From Products to Solutions: When, Why, and How?

A new mantra for many organizations today is to become a solution-centered organization. For some firms it is about enhancing the service content associated with their products and for others it is about extending their reach from selling products to selling experiences. While there is much talk of moving away from the old product-centric form to a new solution-centric organization, there is limited understanding of what this precisely means and how to go about it. In this session w will discuss the multiple facets of effective solutions. Using several recent case studies, we will examine some of the key enablers that allow firms to architect, sell, and implement solutions. Topics will include:

• What is a solution?
• Key facets of an effective solution
• Pricing and selling solutions
• Building solution driven organizations

Relational Capital: Managing Relationships as Resources

Firms are now operating in an ever more interconnected world of business in which they have to connect with other organizations up and down the value chain. However, most firms have yet to measure and manage these key strategic relationships. This session will present the concept of “relational capital” – the idea that firms need to think of their relationships as key assets that must be managed effectively. The session will discuss how to manage relationships with customers, suppliers, alliance partners and across internal business units for competitive advantage. Topics will include:

• The imperatives of relationships
• Redefining external relationships: alliances, suppliers, and customers
• Transforming internal relationships: cross business unit, mergers and acquisitions
• Building interpersonal connections: enhancing trust and creating win-win partnerships

Increasing the odds: Building Strategic Alliances that Work!

Strategic partnerships have become central to success in the present economy, and yet there is evidence that more than half of them fail. By reviewing some of the best and worst practices, you will identify and discuss critical factors for the formation and management of successful alliances. Topics will include:

• The imperatives of forming alliances
• A classification of different types of alliances and the challenges with each form
• Why alliances fail?
• How to build alliances that work
• How to partner with competitors and win
• Creating trust in win-win alliances
• Managing a network of partnerships

Designing Next Generation Organizations

In the present context, firms are witnessing dramatic shifts in the competitive landscape with intensified competition and increasing commoditization of offerings. Consequently, firms are struggling with finding ways to organize themselves to be both product leaders while also getting closer to their customers. They must simultaneously be cost leaders while also being on the cutting edge of innovation. How do organizations deal with these seemingly competing sets of demands? In this session we consider some of the latest organizational strategies that industry leaders are pursuing. The topics discussed will include:

• The architecture of the new organization
• Linking your strategy with your organization
• Core business processes in the new organization
• The role of new leaders in these organizations

Leading and Managing Organizational Change

The vast majority of both major and minor change initiatives in enterprises fail. In this session we examine some of the typical pitfalls that firms face when they embark on change initiatives. We look at new models of successful change and consider both the role of leaders and also of followers in initiating and managing the successful transformation inside organizations. The topics discussed will include:

• How to define a change strategy inside your organization
• A roadmap for executing a change strategy that works
• Balancing top-down with bottom-up initiatives
• Key pitfalls in leading change efforts inside your organization

Strategic Thinking for Turbulent Markets

To achieve success in today’s volatile economy requires leveraging more than just traditional assets. Intangible assets in the form of customer relationship management, branding, organizational design and property rights have become important off balance sheet pillars of competitive advantage. In this session, we learn to think more creatively about leveraging your tangible and intangible assets as you develop strategies for building a sustainable competitive advantage. We will analyze companies in the present context, discuss case studies, and identify how and where you should make changes to the way you think about strategy and resource decisions. The topics discussed will include:

• Identify and explore the essential foundations for building competitive advantage
• Examine some of the newest organizational structures and strategies to continually modify those that work best in a dynamic environment
• Investigate how leading firms in a range of industries use creative strategies to build and sustain profitable market positions
• Cultivate an understanding of how to build competitive advantage through case studies

Transformational Leadership

What are some successful pathways to driving deep change within your organizations? This lecture will provide a comprehensive model for how to develop and guide change within organizations. It will also provide a detailed assessment of the attributes of successful leaders and some thoughts on how to develop such a leadership pipeline within your organization. The focus is not just on senior leadership but also on those in the middle. It will provide a personal leadership roadmap for those seeking to develop those skills in themselves. The topics discussed will include:

• Leadership as dynamic relationship between leading and following
• How to operate as a leader without much formal power
• Mobilizing and driving change from the middle
• Attributes and skill set of a real change leader

Executing on the Promise of Customer Focus

Companies looking to grow in commoditizing markets like to say that they offer customer solutions—products and services bundled into packages that are hard to copy and can command a premium price. But few companies can actually deliver on that promise. Most companies are organized into product-focused business units that allow them to develop deep knowledge and expertise, but that obscure a holistic picture of customers and their needs. Building on my recent research into the challenges of top- and bottom-line growth, I have found that creating customer solutions can be a powerful way to stimulate growth—but only if companies are able to transcend their organizational silos to marshal all of their resources, including new technologies, toward delivering customer-focused solutions. For marketers, making this shift will involve a rethinking of their roles, the development of new skills, and in some cases, and creative agreements with external partners to both keep costs in line and enhance the appeal of solutions.
Using case examples of b-2-b and b-2-c companies, this lecture vividly demonstrates how marketers can creatively develop higher value customer solutions. Topics discussed will include:

• Strategic dilemmas in commodity markets
• Rationale for the rise of customer solutions
• Market impediments to solutions as a key differentiator
• Internal siloes as roadblocks to customer centric solutions

Silo-busting: Transcending Barriers to Build High Growth Organizations

Those firms seeking to make customer centric solutions into something more than just a catchy corporate slogan, have to confront their internal siloes that are typically anchored around products or geography. They face the dilemma of whether to swap out their old siloes with new customer oriented ones or retain the old siloes but then seek out ways to transcend those existing siloes so that they operate in a more synchronous way. This lecture will not only elaborate on when firms should bust old siloes and when they should transcend them, but it will provide a detailed discussion of the tactics to manage such efforts. Managers will learn about to build internal bridges across siloes and gain insights into how to become those effective bridge builders. Some of the topics covered will include:

• When to bust and when to bridge existing siloes
• Strategies for connecting internal siloes to ensure synchronicity
• Individual strategies for managerial survival on the intersection of siloes
• How to become a bridge builder across siloes

Paths of Disparity ....

That way to the privilege of a school, this way to livelihood burdens. Two sets of children present a study in contrast on a Chennai thoroughfare. - Courtesy - The Hindu

Excerpt from AlwaysOn stanford summit ....

some good facts some bad facts is normal in new business ....

Innovation is change, making change happen, making breakthrough happen

Old business - things don't change ....

fundamental change in silicon valley

power of ideas powered by entrepreneurial energy and entrepreneurial passion

sometime the energy is distorted if its been done for monetary benefits ....

There is a lot of infrastructure available now ....... compared to past ...

Its much easier to fail and start now ....

mercenaries who are here just for money cause the distortion to the entrepreneurial energy ...

silicon valley is about ups and downs ..... the real important thing is that
"what is important? and whether the impact can be done to the world for a good cause ?"

innovation and entrepreneurship are the important social tools that can change the world .............

different people are driven by different motivations .... and different people are driven by different motivations at different stages of life

Entrepreneurship should be driven by passion and should NOT be just for money ..........

The above mentioned is an excerpt from AlwaysOn stanford summit by Vinodh Koshla

who runs Internet

WHO RUNS THE INTERNET?
Who controls this web, this cloud, this network of networks? Well, no one, really. The Internet seems to be both institutional and anti-institutional at the same time, massive and intimate, organized and chaotic. In a sense the Internet is an international cooperative endeavor, with its member networks kicking in money, hardware, maintenance, and technical expertise.

The U.S. government has had a big influence on the federally funded parts of the Internet. The National Science Foundation (NSF), as mentioned, initiated the NSFNET in the mid 1980s, a nationwide backbone in the United States that connected many mid-level networks, which in turn connected universities and other organizations.

Credit Risk ...

Crockford, Neil (1986).
An Introduction to Risk Management (2nd ed.).
Woodhead-Faulkner. 0-85941-332-2.

Charles, Tapiero (2004).
Risk and Financial Management: Mathematical and Computational Methods.
John Wiley & Son. ISBN 0-470-84908-8.

Lam, James (2003).
Enterprise Risk Management: From Incentives to Controls.
John Wiley. ISBN-13 978-0471430001.

van Deventer, Donald R., Kenji Imai and Mark Mesler (2004).
Advanced Financial Risk Management: Tools and Techniques for Integrated Credit Risk and Interest Rate Risk Management.
John Wiley. ISBN-13: 978-0470821268.

Bluhm, Christian, Ludger Overbeck, and Christoph Wagner (2002).
An Introduction to Credit Risk Modeling.
Chapman & Hall/CRC. ISBN 978-1584883265.

de Servigny, Arnaud and Olivier Renault (2004).
The Standard & Poor's Guide to Measuring and Managing Credit Risk.
McGraw-Hill. ISBN 978-0071417556.

Darrell Duffie and Kenneth J. Singleton (2003).
Credit Risk: Pricing, Measurement, and Management.
Princeton University Press. ISBN 978-0691090467.