1.  Be aware of your organization’s current culture. One of the significant forces that affect the success of your process improvement efforts is the culture of your organization. Organizations with cultures that are positive toward process improvement are likely to want to supply a quality product with reasonable business returns, have middle managers that are willing to set and work toward targets of meeting your organization’s needs and business goals, and have senior management leadership that is willing to launch and sustain a long-term change effort.
2. Expect to change your organization’s structure and culture. Process, organizational structure, and corporate culture all go hand-in-hand – change one and you will affect the others.
3. Keep it simple. A common mistake that organizations make is to over specify the processes that they intend to follow.  Never forget that your goal is to produce working software that meets the needs of your user community and that your staff likely has a pretty good idea of how to do this although they could help with a little guidance from time to time.  Give them just enough guidance for their needs.  An example of a well defined, yet simply defined, process is the Agile Unified Process (AUP).
4. Align your software process with business goals and objectives.  You could have the best process in the world, but if it doesn’t meet your organization’s goals then it doesn’t matter.  Do you intend to build a portfolio of applications that integrate with, and build upon, one another?  If so then portfolio management is important.  Do you intend to sell shrink-wrapped software to be used by millions of users?  If so then architecture may be less important to you in favor of getting a product to market quickly.
5. Regularly hold retrospectives.  A retrospective is a process improvement meeting where you ask four fundamental questions: What did we do well that if we don’t discuss we may forget?  What did we learn?  What should we do differently next time?  What still puzzles us?  Retrospectives can be simple 15 minute discussions or formal meetings over a day or two.  The goal is to learn from your experiences.
6. There’s a serious difference between “lessons learned” and “lessons indicated”. The result of a retrospective is a collection of lessons indicated, they don’t become “learned” until you actually improve your process.  I’ve been in organizations where we’ve held a retrospective, sometimes called a post mortem or “lessons learned” session, which resulted in a list of really good process improvement suggestions.  Always one to cause trouble, I then asked if the client had any similar documents from four or five years ago.  Comparing the documents, we’ve often discovered significant overlap between the lists.
7. Keep the real goal in mind. My experience has been that software processes, when applied intelligently, increase the productivity of developers. My experience has also been that when processes are applied less than intelligently, or when the paper pushers have too much influence within an organization, processes can also decrease your productivity. Organizations that keep the end goal in mind – that of developing, maintaining, and supporting software that fulfills the needs of their user community – will be successful with implementing software processes. Those that follow processes simply for the sake of doing so are likely to fail.
8. Recognize that the fundamentals remain the same, the details vary. Contrary to popular belief, the fundamentals of software development have been known for many years.  You need to perform requirements engineering.  You need to model.  You need to write code.  You need to test.  You need to perform change control.  You get the picture.  Every successful software organization will have a similar set of processes but the way that your organization brings them in and how they implement them will differ.  Your requirements process may be slightly different than your competitors, but you will both have one that will generally do the same sort of thing.
9. You need more than one process.  You wouldn’t run a project team of thirty people the same way that you would a team of three people.  Nor would you run an outsourcing project the same way that you’re run a project developed by a co-located team.  Nor would you run a data warehouse project the same way that you’d run a .NET application.  You need different processes, or at least different flavors of your process, for different situations.  Use the right process for the job.
10. Run a trailblazer project to validate your new processes. Regardless of how well you define a process, no process is perfect.  Test your new software process using a trailblazer/pilit project, one that is given the extra resources required to try new techniques and to update them appropriately.
11. Treat process improvement like a project.  Have an experienced project manager, ideally someone with experience in both process-oriented and object-oriented development. Define the requirements for your processes, model them, implement them, test them with a trailblazer project, and then improve the processes.
12. Improve your processes in priority order.  The reality of process improvement is that you cannot make all of the changes that you want to immediately; it is simply too great a change for your organization to absorb at once. This is why we have efforts such as the Software Engineering Institute’s (SEI’s) Capability Maturity Model Integrated (CMMI) efforts and the Software Process Improvement Capability Determination (SPICE) efforts of the International Standards Organization (ISO). Both of these organizations suggest that you prioritize the process improvements that your organization needs to make, expect that it will take several years to make the needed changes, and expect that you will experience difficulties while doing so. There are five maturity levels in the CMMI for a reason: you need to progress in order from level one to level two to level three and so on.  The implication is that by knowing which aspects of a software process map to which CMM maturity levels you have a rough idea of the order in which you should introduce those processes to your staff.  Experience shows that organizations that try to make immediate, large-scale process changes are likely to fail doing so. The reality is that it takes time, often several years, to permanently improve the productivity of your software development efforts. There is not a simple, quick fix to your problems.
13. Communicate your plan.  It is essential that you let others know what are you doing, why are you doing it, the business case for it, success stories, etc. Keeping them informed on how things are going, even if you are encountering difficulties, will help get them (and keep them) on board. There are various options for this: a newsletter, a web site, periodic emails to key personnel, etc. Trumpet your successes and share your lessons learned with the appropriate people.
14. Accept that the big picture is overwhelming.  Because of the complex nature of software development most developers specialize in one aspect of it and focus solely on that.  This becomes a problem for organizations that wish to tailor a software process for their exact needs because when they put the individual pieces together the overall process becomes very large.  For example, the Rational Unified Process (RUP) is over 3,000 HTML pages in size, and it is only a development process.  Once developers see how large your organization’s software process is they often go into denial, claiming that you can not possibly achieve your goals.  Yet when you ask an individual which part of their process they can simplify they’ll often balk at the idea.  An alternative approach might be something such as the Agile Unified Process (AUP), which is a bit smaller (it’s around 30 HTML pages).
15. Democracies do not always work, nor do dictatorships.  Organizations that wish to reach consensus regarding their software process tend to flounder. You’ll never achieve complete agreement on how things should be done, although organizations that dictate processes from above tend to fail as well.  Effective process improvement efforts seek consensus at some points and dictate things at other points.
16. Identify the consumers and suppliers for each process. Every process has inputs and outputs, and you need to ensure that there is a supplier for each input and a consumer for each output.  Fundamentally, if nobody is going to use an artifact that is produced by a given process then why bother producing it?  You also need to look at collections of processes to see if the artifacts that they produce add value in combination.
17. Defining a process is the easy part. Many organizations are very successful at defining a software process, often producing binders (or web pages) of documentation.  However, when I’ve revisited these organizations a few months after introducing a new process it will be all but forgotten.  Getting people to accept your new process, and making the changes that go along with it, will take significant time and effort to accomplish.  Writing a process is the easy part, following it is the hard part.
18. Introduce a Software Engineering Process Group (SEPG) to your organization. The sole responsibility of your SEPG is to support the definition and improvement of your organization’s software process. The SEPG should be kept small – as a rule of thumb, we suggest one SEPG member for every one hundred developers in your organization.  SEPG efforts are a component of the EUP’s Software Process Improvement (SPI) discipline.
19. Staff your SEPG with actual practitioners.  The people who best understand how to develop software are the people who are very good at developing software.  Yes, that sounds blindingly obvious, but what isn’t obvious is that they are usually the best ones suited to define your software process.  Try to staff your SEPG mostly with current practitioners, people who are now managers but had did some COBOL programming 20 years ago are often poor candidates, although include some people with a process background to ensure that they’re not reinventing the wheel.
20. Reuse existing process materials.  There is a wealth of process materials out there, you very likely don’t need to write your own.
21. Avoid “fire hazard processes”. A common mistake is to produce volumes of documentation describing your processes. Your goal is simply to describe your process materials to such a level that they can be given to a professional skilled in the techniques of that process so they can work the processes appropriately.
22. Adopt processes because they make sense. If a process makes sense to you, and you believe it will add value to your effort, then adopt it.  Otherwise, do not.
23. Hold everyone responsible for process improvement. Senior management must be willing to actively support and sustain process improvement, project managers must be held responsible for ensuring that their teams follow the defined processes, and developers must be held responsible for learning and then following the processes. This is often a difficult task because senior management often demands immediate results, whereas process improvement often takes years. Project managers resent diverting scarce resources from their projects, and developers often resent being told how to do their jobs.
24. Bring in an expert to advise you. Process improvement is a complex and difficult endeavor, one for which you are likely to need help to accomplish. You can increase your chance of success by bringing in a consultant who has both a process background and an OO development background – someone who has been actively involved in a process improvement program and who has worked on large-scale, mission-critical software development projects using OO technology.
25. Do not think that everyone is on board. There is likely to be a small core of people within your organization who do not want to use object technology for large, mission-critical projects, and these people will actively undermine your efforts. You need to identify these dissenters and work together with them to help them see the advantages of working with object technology and of following a set of defined process patterns to help in the development OO software.
26. A fool with a process is still a fool. For your organization to be successful with a software process your software professionals will need to understand the processes, the concepts, the techniques, and the problem domain. Implementing a new process in your organization involves more than going out and purchasing a couple of new books and development tools.
27. Develop a user guide for your process. You can make it easy for your staff to learn your chosen processes by providing a well-written overview of your process as it is to be implemented in your organization.  In fact, this may be all the process material that you need.
28. Have patience. Progress will be slow at first, slower than you hoped or expected. Introducing a software process into an organization takes time – the required culture shift often takes years to complete.
29. Don’t flounder in bureaucratic requirements. Too many process efforts run aground because of preconceptions forced on them by senior management, an overly burdensome documentation and review process, or unrealistic requirements to achieve consensus.
30. Define your process early. The longer you leave process definition the bigger the mess you will have to clean up.  Without direction, developers will typically go and do what they think is right, the only problem being that each person has their own idea of what “right” is.

This initial discussion is intended to offer HR a new way of making a significant contribution to an organisation’s strategic and operational goals.

The crux of the initial report is that it encourages open discussion among the HR community by asking questions motivating readers to take part in a debate informing the second stage of the research.

Martyn Sloman, learning and development adviser at the CIPD and key-note speaker at its Recruitment and Retention conference on 18-19 June says: “Web 2.0 has the potential to change the way people interact and work. But, like every new form of technology, there are challenges and degrees of risk. HR must be aware of this in order to advise senior management teams and influence strategy.

“We are hoping that the HR community participate fully in our discussion document and post their opinions so that we can not only inform but also seek answers to relevant issues in the second stage of the research.”

Development in technology give rise to use of technology for HR.

The Wipro Enterprise Data Centres (WEDC) would also be the platform for launching Wipro’s Cloud Computing services for the India and Middle East Markets, for customers to avail services on a pay-per-use model. Both Data Centre Life Cycle Management services and Cloud Computing services will offer a high level of flexibility to customers with respect to service delivery and costs.

Commenting on the launch Mr. Anand Sankaran, Senior Vice President and Business Head, India & Middle East, Wipro, said: “Wipro has been addressing the IT needs of customers for over two decades now. To complete our portfolio of offerings, we felt the need to offer best-in- class Data Centres, as well — which resulted in the launch of Wipro Enterprise Data Centre. Enterprise customers today are seeking services beyond simple hosting and co-location, and this is a very strategic move by us and positions us uniquely to cater to the lifecycle needs of enterprises as a single face.”

These Tier III WEDCs provide a platform to offer complete Data Centre Lifecycle Management Service to customers. Organizations can leverage Wipro’s technology expertise and decades of experience in managing multiple IT environments, cutting across various verticals. Data Centre Lifecycle Management service comprises solution design, implementation, co-location and management of the complete IT infrastructure.

IT Infrastructure and Applications that are deployed at WEDC will be managed from Wipro’s state-of-the-art Global Service Management Center (GSMC) in Mysore. This service will enable enterprise customers maintain their strategic focus while improving their operational efficiencies.

Apart from the traditional Data Centre model, clients will soon be able to avail Wipro’s Cloud Computing services that offer IT infrastructure and specific Business Applications as a service. These services will cover the entire IT Infrastructure including Compute, Storage and Backup, Network and Disaster Recovery, in addition to Applications that address specific business needs of customers.

Further, in keeping with its commitment to ecological sustainability, Wipro has deployed Green technologies at each of these centres to help both customers and Wipro reap the benefits of energy efficiency and savings.

Wipro plans to achieve a pan-India presence for its Data Centres and expand this service to offer more value-added services to clients.

Wipro is not new in the Data Centre or IT Infrastructure space. It is has been offering services to global clients through Infocrossing (a Nasdaq-listed IT Infrastructure company) which it acquired in 2007. Infocrossing comes with over 25 years of experience in managing IT infrastructure and applications for a host of customers across the USA.

The lab aims to help organizations deliver the visibility, control and automation needed to address quality service, manage risk and compliance besides maximizing return on investments, and accelerate business growth.

Dr. Ponani Gopalakrishnan, Vice President, IBM India Software Lab said “It’s time to start thinking differently about infrastructure. In this smarter world, we need our assets to propel us forward, not hold us back. A dynamic infrastructure transforms physical and digital assets into higher valued services. It is highly optimized to achieve greater results with improved service management, and leverages new technologies and strategies to reduce costs, manage risk and deliver superior business and IT services with agility and speed. With the launch of this lab, we are today in a position to showcase some of our own best practices with our clients in India/South Asia region”.

IBM Software Labs in India supports a heterogeneous environment and hence is very similar to a typical growing organization’s IT infrastructure. Using energy monitoring systems along with advanced Virtualization and automated management, IBM is looking to increase operational efficiency by over 20% and in turn increase its green footprint.

“In today’s challenging business environments, customers see the value that IBM brings to the table. The Dynamic Infrastructure Lab will help clients reuse existing capital and increase optimization of their assets by better monitoring their infrastructure and increase operational efficiency” – said Rekha D Garapati – Director – IBM India Software Labs.

Global connectivity is driving increasingly complex supply chains, ultra-empowered consumers, and making issues such as governance and compliance, managing risk, and fending off security threats increasingly difficult and complex. And, with one-third of the world’s population on the Internet by 2011, four billion mobile web subscribers today, and the staggering amount of data and intelligence being driven by the rapid proliferation of smart sensors, RFID tags, and intelligence being built into everything from pets to power grids, the world’s infrastructure is at a breaking point.

IBM has a broad set of offerings for servers, storage, networking, software and services that help clients with their implementation of a dynamic infrastructure. It is a good initiative taken by IBM to manage IT infrastructure.

1. Leaving computer logged on
2. Unauthorised network/facility access
3. Having Security software or Hardware is not sufficient.
4. Sharing Information

Most of us leave there computers logged on when we are away from desk and this happen when we are sleeping also. Thereby creating potential theft incidents and access to personal and corporate data.

Six months ago, Raichura relied heavily on a telecom operator’s infrastructure as his capital expenditure (capex) resources were not sufficient enough to set up an IT infrastructure.

But the back-end connectivity that linked the banking platform to a telecom link on a real-time basis could neither handle the growing demand for space nor efficiently manage the dense networks. That’s when he switched to cloud computing.

Today, his company sends out 200,000 messages a day and 4 million on average each month — nearly 25 per cent more, and without any additional capex. “My operations are on basic cloud services, which are at least 30 per cent cheaper than a dedicated infrastructure, and I can scale up as per requirement,” says Raichura.

In a downturn, start-ups and small and medium enterprises (SMEs) in India, key to the economic revival, are embracing cloud computing — a virtual computing environment that uses the Web to work on a variety of operating systems, loading custom applications, and running them with as many systems.

Amazon pioneered this process, with its Elastic Compute Cloud. IBM, which invested $100 million in its 13 global centres, Rackspace, Sun Microsystems and Google (gmail is the biggest example of cloud) are key players in this $14-billion market, which could grow to $42 billion or 25 per cent of global IT spending by 2012. In India, the market potential is just over $1 billion.

TCS, Infosys and Wipro are investing in creating special teams to explore opportunities for creating private clouds for big companies. Utilities such as Reliance Energy, and large business groups such as Aditya Birla Nuvo are also said to be considering private clouds.

Others are tapping cloud computing for specific projects: a leading automaker runs a customer reward programme; a few broking firms are testing mobile stock portfolio management; hospitals trying it for online medical records; news channels using it for interactive programmes or snap polls; and banks (Yes Bank and ICICI Bank) testing customer applications.

Netmagic Solutions, which began with 1,000 servers a month ago, has signed up 10 customers and expects a 30 per cent growth in demand for cloud space. A basic cloud service operation costs a paltry Rs 7,000 a month (maintaining this through a dedicated server and staff would cost Rs 20,000) against an investment of Rs 3-5 lakh for a similar owned infrastructure, complete with servers, firewalls, load balancers and switches. For around Rs 10,000, one can get disposable server resources, and for Rs 20,000, a dedicated hosted ‘cloud’ infrastructure is yours to meet large enterprise requirements.

Experts say India, which jumped the IT infrastructure curve earlier, can benefit from cloud computing if it solves fundamental disadvantages. Apart from safety of the data if hosted on a third party infrastructure, the potential loss of control on one’s key properties is a major hindrance to cloud’s growth. No bank, for example, could risk a payment gateway on the cloud.

In India, high-speed internet connectivity will remain an issue. Private experts argue that at some stage the costs can surpass the traditional hosting in case of very high usage.”

“Our continued recognition by industry experts is something we pride ourselves in,” said P.R. Krishnan, infrastructure services head, TCS. “Today, businesses are increasingly focussed on transforming the way they operate and an effective IT infrastructure is a strategic enabler. TCS’ in-depth industry knowledge and technical expertise helps customers harness the best out of their IT investments by creating a ‘Business Effective’ IT infrastructure that’s not only reliable, but also future proof.”

In some usages, infrastructure refers to interconnecting hardware and software and not to computers and other devices that are interconnected. However, to some information technology users, infrastructure is viewed as everything that supports the flow and processing of information.

Infrastructure companies play a significant part in evolving the Internet, both in terms of where the interrconnections are placed and made accessible and in terms of how much information can be carried how quickly.

More business transactions occur electronically every year, and midsized organizations are retaining a growing volume of sensitive data. This data is available to an expanding user base, including employees, trading partners, suppliers and customers. IT infrastructures are more extensive, more complex, more distributed—and more accessible. This accessibility is making organizations susceptible to attacks and intrusions from ever-increasing and evolving threats.

When an attack compromises data, an organization faces customer service issues and lost revenue, data and productivity, some of which might be unrecoverable. Adding to this challenge is the need to retain data to meet regulatory compliance or auditing requirements—losing this data could create severe consequences to your bottom line and reputation in the form of fines or even closure of your business.

Monitoring IT infrastructure is one way to prevent attacks and protect data, systems and networks from malicious threats. However, you are often presented with an array of solutions that might not afford you the protection necessary to keep not only your systems, data and networks safe from attacks, but also your investments and brand.Monitoring IT infrastructure is one way your company can protect classified information. But a wide range of security solutions makes it hard to choose the one that’s best for your organization.