Earned Value Information

Earned Value InformationUse the EV fields to track work performance to account for cost and schedule variances. The following earned value data fields are included and can be displayed on list pages and portlets:

ACWP
Read-only. Displays the system-calculated value of Actual Cost Of Work Performed (ACWP), which is the total direct and indirect cost incurred in performing work during a given period of time based on posted actuals.
Calculations are made based on the level at which the calculation is being made. ACWP is calculated at the following levels:
Detail-task. The calculation is based on the following formula:
ACWP = Actuals Work Units * Billing Rate
Summary-task. The calculation is based on the following formula:
ACWP = Sum of ACWP for all detail tasks in project
Project. The calculation is based on the following formula:
ACWP = Sum of ACWP for all WBS Level 1 tasks in project

BAC
Read-only. Displays the system-calculated value of Budget at Completion (BAC), which is the budgeted total cost at the time of the baseline, based on the following formula:
((Actuals + Remaining Work) x Billing Rate) taken at time of baseline

BCWP
Displays the system-calculated value of Budgeted Cost of Work Performed (BCWP). This value is calculated and recorded when you baseline your project or when you update earned value totals and is based on the cost and rate matrices associated at the project level. BCWP is also referred to as the earned value (EV).
Calculations are made based on the level at which the calculation is being made. BCWP is calculated at the following levels:
Task. BCWP is based on the selected EV calculation method.
Project. BCWP is the sum of BCWP for all WBS Level 1 tasks in the project.

BCWS
Read-only. Displays the system-calculated value of Budgeted Cost of Work Scheduled (BCWS), which is the budgeted amount to be spent on the project in a given period of time. This point is either the project's as of date or the system date if the project's as of date is not defined. BCWS is also referred to as the planned value (PV).
The BCWS is calculated based on the following formula:
BCWS = Sum of BAC through a point in time

CPI
Displays the system-calculated value of Cost Performance Index (CPI), which is an efficiency rating for work accomplished, based on the following formula:
CPI = BCWP / ACWP
Note: A value greater than one indicates the costs are running over budget.

CV
Displays the system-calculated value of Cost Variance (CV), which is the value of what has been accomplished to date versus what has been spent to date, based on the following formula:
CV = BCWP - ACWP

EAC
Read-only. Displays the system-calculated value of estimate at completion (EAC), which is the total cost of all actual work completed to date plus the predicted cost finishing the remaining work, based on the following formula:
EAC = ACWP + ((BAC - BCWP)/CPIc)

EAC (T)
Read-only. Displays the system-calculated value of estimate at completion (EAC). This calculation is most often used when current variances are seen as typical of future variances, and is based on the following formula:
EAC (T) = ACWP + ETC

EAC (AT)
Read-only. Displays the system-calculated value of estimate at completion (EAC). This calculation is most often used when current variances are seen as atypical and the project management team expectations are that similar variances will not occur in the future. This value is calculated based on the following formula:
EAC (AT) = (ACWP + (BAC - BCWP))

ETC (Cost)
Read-only. Displays the system-calculated value of estimate at completion (ETC). This value is calculated based on the following formula:
ETC (Cost) = remaining labor cost + remaining non-labor cost

ETC (T)
Read-only. Displays the system-calculated value of estimate at completion (ETC) using earned value data. This calculation is most often used when current variances are seen as typical of future variances. This value is calculated based on the following formula:
ETC (T) = ((BAC – BCWPc)/CPIc

ETC (AT)
Read-only. Displays the system-calculated value of estimate at completion (ETC) using earned value data. This calculation is most often used when current variances are seen as atypical and the project management team expectations are that similar variances will not occur in the future. This value is calculated based on the following formula:
ETC (AT) = BAC – BCWPc

SPI
Displays the system-calculated value of Schedule Performance Index (CPI), which is the ratio of work performed to work scheduled, based on the following formula:
SPI = BCWP / BCWS
Note: A value less than one indicates the work is behind schedule.

SV
Displays the system-calculated value of Schedule Variance (CV), which is the value of what has been scheduled to date versus what has been performed to date, based on the following formula:
CV = BCWP - BCWS

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.