OGC CAR - Negotiated Procedure, the rocks and the rapids of community perception

There has been a certain amount of debate in recent weeks as to the effect of the OGC CAR project on the future of ITIL. Some of this debate, in my own opinion only has bordered on hysteria and so I think that it might be helpful to try to add my own understanding to that that has been already published with regard to what OGC is actually trying to achieve through these two paralell processes and how it is going about it.

My understanding, and that of those 'in the know' who I have spoken with about this is that the CAR European Journal Adverts were seeking:

"expressions of interest in the provision of accreditation and publishing services related to a portfolio of OGC best practice products."

The two key words here are:

1) Accreditation
2) Publishing

Against this backdrop, I believe that:

1) The OGC is retaining complete editorial control of ITIL
2) The OGC will continue to 'own' ITIL
3) The publication rights are being negotiated with TSO (formerly 'The Stationary Office') who have been responsible for publication for the past 10+ years in anycase, the issue here is rights to produce new media etc etc.
4) The biggest change is with regard to the 'Accreditation/Certification' control that is being negotiated with APMG.

Some commentators (see the debate at the ITSM PORTAL) have suggested that all the rights will go to one party, this is not what I am reading in the OGC press releases that I have read - I think it is very much 'accreditation/certification' to APMG and Publication to TSO.

Accreditation/certification:

A) APMG is already responsible for Prince II, MoR and MSP guidance from the OGC and has been effective in promulgating Prince II based appraoch as a standard.
B) It has been suggested that the APMG has not managed a qualification as 'credible' and 'solid' as the Managers Certificate (ITIL) - specifically they seem to have done okay on Foundation and Practitioner levels with the other areas but they are not (i believe) as rigourous as the ITIL ones. It has been suggested that there is a risk - that ITIL qualifications will be devalued and practitioners/managers will become less well respected as a result.
C) There is a possible 'counterbalance' to this in that I haven't read anywhere that the ITIL Certification Management Board (ICMB) will be disbanded, this provides BCS, EXIN (and I think ITSMF) input to the qualification scheme. If this is maintained, even if the scheme is managed/run by APMG then an element of independent quality control will remain.

Publication

On the publication side, and depending on the freedoms offered in the contracts (which will typically be restricted rights licenses):
A) Contrary to many suggestions that I have read posted over the past few weeks - as far as I understand ITIL is not being sold (it is reported that OGC was offered a lot of money by Microsoft some years ago and if they were going to sell they probably would have then).
B) It is possible that with a little more freedom, TSO will improve the quality and usability of the electronic references and be able to invest more heavily in common diagramatic themes etc, making the works more acessible.

Commentators have raised concers that the ITSMF may loose its close ties to ITIL, (in my oppionion, this would be a great shame), but similarly it is perhaps time and a good idea that the ITSMF considers widening its umbrella and comments/reviews/QAs other best practice frameworks as ITSM ceases to just be about ITIL and encompasses guidance and audit within ITIL, CoBIT, MOF and other frameworks.


The effect on the historic success of ITIL

ITIL has historically beed adopted and adapted and is well regarded as a good volume of work because:
- it isn't shelf breakingly large,
- it covers much (but clearly not all) of the territory required of a good IT-ERP practice guide,
- it is produced by an independent (of vendor bias) body,
- it is commercial only through publication and certification not in it's objective
- it carry's a government seal of approval making it's promotion in large corporates / public sector easier than some 'consultant babble'.
- there is (currently) some significant value in certification making it easier to encourage staff to train in it.
- it has been tried tested and evolved over a considerable time.

Some of these have negatives:
- it's organisation sometimes means moving between 'books' to gain a complete picture of the activities, processes and approaches reccomended to address a particular service management need
- consistency in format, presentation, tone and occasionaly content is not perfect as a result of the multitude of authors, the temporal distance between publications and perhaps a lack of editorial oversight
- the lack of an 'active' sponsor marketing ITIL (other than the ITSMF) means that 'promotion' ends up being done by consultants or worse still vendors with an agenda so sometimes it is mis-represented.
- the 'government' processes for update, review and management sometimes make it slow moving and slow to respond to real world needs (e.g. Security Management is woefully inadequate for electronic integrity, privacy and confidentiality discussion).
- staff 'adiction' to process can emerge resulting in processes hindering rather than supporting the business if ITIL is adopted as an objective, rather than as an aid to supporting an improvement programme to support the business.
- it's longevity has led to some inconsistency, weakness in some areas and some 'baggage' that some practitioners are attached to making change more difficult - we will have to see how the refresh deals with this without throwing the baby out with the bathwater.
- The current focus on Service Management (Red+Blue) in the 'wild' means that there is a risk that attention is not paid (especially) to the 'Orange book'. - I have a collegue who after reading (yes he did) the Red and Blue books said, okay so i've hired, nominated or appointed all of these process owners and managers now where does it tell me who does the work and what they need to do?


ITIL and the OGC

The OGC CAR is clearly a 'change' in the commercial relationships around ITIL, but the proof of OGC's intention will be in the 'eating'. If, in two years time, we still have :
- High quality not exhorbitantly priced manuals
- Good electronic access options
- Independent editorial control with a wide range of industry representation
- attention to the 'small guy' as well as large corporate, consultants and government
- a certification system that is respected and where the top level qualifications are still considered 'hard' work and 'valuable'.
- a significant degree of industry 'buy in'.

Then the project will have been a success.

As with any big 'change','project','deployment','programme' we must consider the risks and the impacts, the costs and the benefits (in this case to both the OGC and the community) and respond on the basis of fact and information rather than emotion and 'fear of change'.

I wasn't involved in any bids and so can't comment on what APM, ITSMF, TSO or others will or will not have included in their bids, but (from the OGC):

"The licences will include the right to publish books, CDs and other reference material under the OGC brand, in addition to providing accreditation services on behalf of OGC."

It appears that some people have 'gotten' the wrong end of the stick and believe that editorial or content control is being handed over. OGC directly will retain full control of the (c)Copyright and so the integrity of the 'Best Practice' should be protected. In fact, TSO have held the publishing contract for as long as it has existed and the core works have existed within that framework without problems, while clearly the spirit of 'community' and some commentators desire to see 'best practice' become a pseudo 'open source' type endevour there is a belief that these publishing rights to be held by the community perhaps such as the ITSMF to whom they might represent a welcome boost to income and therefore the promotion, support and development of the community - I personally don't see why it is neccessary.


The ITIL Community

The ITIL community has a lot of valuable input to bring and the OGC would be ill advised to ignore it as would any commercial partner that they appoint. It will however be too easy for them to brand us with labels:
- Disgruntled ITSMF member
- Indignant IOSM member
- Excluded vendor
- Biased consultant / third party author
- etc
and use these to ignore the community. Probably the most powerful defence that the SM community has to protect its interest is it's experience, strength of feeling, influence and the fact that by and large it is populated with well educated, erudite individuals with much real-world experience. Unlike many other areas (e.g. in SW development) ITSM is not as far as I have seen overburdened by academics (* note to academics - academic research, evaluation and input is without doubt valuable - but in creating best practice I believe that experience and empiricism trumps all theory).

Like others, I have the same concerns with regard to the editorial future control of ITIL, but believe that in light of the considerations (above) they may well be unfounded. I believe that best practice *MUST* draw on the wider community both the existing community and emerging broader international community.

A Personal View

Most of us who contribute to Best Practice do so because we develop it as a part of our job, engaging within and without our employers and as a common basis that we can share, debate and improve by working with our peers. The ITSMF is an excellent forum for this and I don't see this role being threatened. Indeed, the ITSMF's right to publish in the area of Service Management also won't be affected and I suspect that OGC will continue to be generous with the use of the ITIL trademarks etc, provided that the commercial value of the publication rights for the core works are protected.

With regard to certification, the water seems a little more muddy. Again, currently this is done more 'directly' by OGC for ITIL (not for PrinceII, MSP or MoR which have been with APM for some time already). The level of change to the current arrangements remains to be seen, but, again quality should be our concern here and as far as I am aware it is not clear, but it seems to be expected that both ISEB and EXIN will be retained by the successful bidder as 'Examination Institutes', perhaps with a little more centralisation of Sylabus and Examination content. Having looked at several ITSM and ICTIM Managers Exams over the past year from both institutes, there is certainly considerable room for improvement, although I think that the rigour and level is good, often the quality of questions and case studies could be improved. This is probably a symptom of the financial constraints and level of peer review of the papers before publication so there may be opportunities that arise if the commercials are more clearly sorted out. . . Again, I haven't looked at the documents recently and certainly don't know the contents of any bid. It seems likely that EXIN / BCS bids for the accreditation may have been weakened by excluding (either actually or practically) the other from involvement, while APM may have left collaboration with both open. APM, while small has a track record of operating and certifying large numbers of people within the disciplines that they do understand, and (as an aside), it would be poor judgement to ignore the overlaps between Prince2, MoR and ITIL; there is much in ITIL 'Deployment' that overlaps with Prince2, much from MSP that should be included in the 'Orange Book' successor either by reference or inclusion and Risk Management is currently sorely lacking from ITIL and a vital inclusion. There is common ground and APMs existing qualification schemes and infrastructure may well allow it to operate on a better commercial footing than BCS/EXIN/ITSMF in offering certification. Perhaps they didn't make a cash bid but made a 'profit share' bid supported by their Prince2 experience and as a result of savings in scale and across multiple qualifications were able to reduce their costs and so tender more in total, perhaps ITSMF bid only for one element (ITIL) and OGC are legally bound to seek efficiency and so a credible bid for all qualifications would be a 'better deal' for them.

I believe that excluding ISEB(BCS)/EXIN from the examinations (as partners or providers) will simply result in fragmentation; there would be nothing to stop them offering very credible 'Service Management' examinations based on their experience to date. In fact in Project Management, BCS/ISEB already offer a very credible qualification that subsumes Prince2 (and so demonstrates that they can work effectively with APMG) by providing detailed PM training and covering the Prince2 process at the same time.

So to summarise, as I read it : Nothing is changing with regard to Prince2, MoR, MSP or the ITIL Core Texts, all of which will continue to be published by TSO. Nothing is changing with regard to Prince2, MoR or MSP accrediation/qualification which will continue to be administered by APMG. It seems likely that ITIL accreditation/qualification will move to APMG as well, it is unclear whether this will result in APMG adopting the chair of the ITIL Certification Board and accrediting the Examination Institutes (similar to current model), or whether it will go further with them actively setting syllabi and exams to be administered by existing EI's, whether they will seek to do everything themselves or whether something different will emerge.

It's good to see this issue raising such passion, unusual for Best Practice to arouse such strong feeling but a 'sense of ownership' within the community is surely only a positive thing for the future.

References:
ITIL CAR at www.itil.co.uk
OGC CAR Statement at www.ogc.gov.uk

Technorati Tags: ITIL , Service Management , Best Practice , OGC , Prince2 , Project Management

Avoiding supplier management problems in SLA's and Contracts

It's a re-occurring theme that we often encounter at IXIF - we are contacted to "help with some supplier management issues", the client (often new to their job) is having significant problems with a key supplier usually the provider of a critical, but outsourced, support service or vital business application.

The three most common problems we encounter are:

• Lack of a common, well understood Service Level Agreement (SLA)
• Contracts that are inappropriate, inconsistent or badly produced
• Unmanageable (unmonitorable/unenforceable) contractual performance criteria
  

Of course it's our job to help and so after the usual commercial niceties we start to work through the issue(s) with our client. Often we very quickly discover that the contract or the SLA have not been examined in some time and that, when they are found, they are both documents of a weight more appropriate to keeping doors propped open than being a 'quick reference' to the details of the working relationship between supplier and customer.

How does this happen? I have a suspicion that too often these contracts and SLA's (and yes - the two are and should be separate documents) are drafted by lawyers for one party or the other. Usually on investigation the biggest, thickest documents are the result of lawyers from both sides working flat out for weeks, producing documents, entire sections of which may never even have been read by the business (although it's rare that people will acknowledge that).

"What's wrong with that?", is the typical response when we make the observation - "surely you're not advocating keeping the lawyers out of the process?". As far as the SLA is concerned, yes, I'm am very tempted to suggest to most clients that their SLA's are not drafted (or even edited) by a lawyer! If a lawyer needs to review the document and make suggestions - of course he/she should. In fact, I believe, that as many senior staff and advisors as possible from within the business should review draft SLA's and comment on them. The SLA is the business definition of what is expected from the deal, it should be in business language, clear, understood by everyone and ideally short. I haven't encountered an SLA recently that couldn't have been written in less than 25 pages.

The contract, of course, will be drafted by the lawyers. The biggest mistake that often happens here is the 'leave the contract to the lawyers' approach. Very few clients are lucky to have a corporate counsel who understands the business requirements as well as they do and fewer still have the funding to ensure that a lawyer is intimately involved in every step of the requirements definition, business case and negotiation. The upshot of this is that a senior representative of business IT needs , whether the IT Director, CIO or Finance Director or the Project Executive or Project Sponsor (where this is a new system) needs to be very involved alongside the Service Level Manager/Service Delivery Manager for the negotiation of every agreement. Often, we find that it is an excellent exercise to take the SLA and then to write a summary of all of the 'non-service' items that are a concern from a business perspective and to use this as the agenda for the first meeting with legal counsel. Hopefully, this outline with the expert input from the lawyer who will have their own list can be developed to form the backbone of the contract. When for reasons of cost, policy or speed a boilerplate contract must be used then I am startled as to how infrequently the business and IT staff responsible have read through, understood and questioned every section of it before they start work on editing and adapting it. Too often it's not clear what every clause means in business terms, not evident that all clauses are necessary and uncertain that the document accurately reflect the needs of the business. The boilerplate contract used by many organizations 'contracts' department may be ideal for a cleaning contract, or for the supply of paperclips - but is it flexible enough, or the right place to start, when the need is to accommodate an IT system that is critical to the business and likely to undergo significant and regular change. Are the savings realised through using a boilerplate SLA or agreement justified given the business importance of the IT service under contract?

Once we've overcome the initial hurdle of finding and understanding the contract and the SLA we sometimes find that this is enough to resolve the problems. Often we find that the 'supplier problems' or 'customer problems' arise from the fundamental lack of working relationship that can so quickly arise when staff on one or both sides have moved on and new people are left (sometimes without understanding of or reference to) the contract and the SLA to manage. If the SLA and contract are adequate, often simply a process of communication, clarification and re-alignment around the agreements can make a real difference. Expectations are everything and both sides must understand the expectations of the other and of the agreement(s) into which they have entered.

Where re-aligning expectations and re-focusing on the original agreement proves inadequate, where renegotiation becomes necessary or when negotiating SLAs for the first time the key is to make sure that the SLA and the contract are 'manageable'.

Chambers 21st Century Dictionary defines:
management (noun) 1 the skill or practice of controlling, directing or planning something, especially a commercial enterprise or activity.

So how do we exercise management within an IT service contract. The keys (from our definition) are:

• control
• planning
• direction

Many of our clients have adopted established 'best-practice' such as The IT Infrastructure Library (ITIL) assist with operational planning and strategic direction of their IT Services, and to provide tested techniques and approaches for control. Others either through neccesity (imposed by regulation e.g. Sarbanes Oxley) or as a matter of improving their own internal governance apply standards for governance (such as COBIT) in order to provide a formal approach in demonstrating good control. All of these 'best practice' approaches require that we effectively manage our Service Level Agreements and third party Underpinning Contracts.

Fundamental to this control, planning and direction is information. Information about the needs of the business, information regarding the availability, capacity and performance of the IT services and about the effectiveness, efficiency and performance of the IT service support.

Often we find organizations that feel that they have 'tight' SLA's where 'target' levels of availability, capacity, performance and even effectiveness and efficiency have been included but where these have not been aligned with the business needs at all. A favorite example of mine is from a colleague who encountered an organisation that had negotiated hard for a 99.98% availability in their SLA (a little over 10 hours per year of downtime), but had permitted 2 hours per week of 'neccesary preventive maintenance' with no limitation on when this was performed. The client then complained when the service provider wanted to perform system maintenance every Thursday afternoon from 3pm to 5pm effectively closing down the entire business. Another client thought that an hour of downtime each week would be acceptable (probably correctly, and saving thousands of pounds on their contract) but then had serious problems with their system when the reliability was poor, the system throwing out all 1000 users five times a day for a week but still achieving their 'uptime' requirement.

Another common problem we see, is a contract imposing tight controls such as a high degree of availability (e.g. less than 2 minutes downtime per week), specifying the maximum number of outages permitted (to overcome the second problem detailed above) and perhaps even maximum durations for any single outage - but implementing no method to measure and therefore manage these parameters. This can lead to expensive and prolonged arguments with service providers, where the customer insists that the SLA is being 'breached' but can only provide anecdotal, 'diary' or Service Desk evidence to support their case.

Recently there has been a trend during the contracting process for customers to insist that their supplier perform monitoring of the systems to be supplied and provide reports on a monthly or quarterly basis at service review meetings. This might initially seem to be a good idea, but, often it just serves to provide the supplier with the ability to charge for something that they should already be doing and unfortunately can increase the temperature and reduce the quality of relationships between the client and supplier. In these cases, service review meetings can degenerate into 'bun-fights' as the client insists that service has been bad and the supplier tables graph after graph and table after table demonstrating their compliance with the letter of the contract.

Without their own contract monitoring data, clients are vulnerable to the few unscrupulous suppliers who are happy to doctor their figures to avoid contractual penalties and worse still to deadlock situations that quickly degenerate into:

Client: "The system has performed very poorly"
Supplier: "As you can see from these 50 graphs as summarised in the tabled RAG report we have met or exceed service levels throughout the period"

These discussions often fail to reach a resolution and leave the customer dissatisfied with the service and the supplier. In our experience when client and supplier both implement their own independent monitoring significant advantages:

• Supplier Proactiveness - Often the very act of introducing client side service assurance (monitoring) prompts a considerable increase in supplier side monitoring leading to an immediate improvement in supplier reaction speed and pro-active problem identification.
• Honesty- Suppliers appear more quick to admit to problems and rectify them (often before service reviews), where there are discrepancies in monitoring both parties can engage 'together' in determining the cause of the difference, agreeing a way forward and either improving service within the contract or enhancing the SLA to facilitate improvement.
  
• Trust & Communication- Customers are able to act quickly and engage with both suppliers and users when problems emerge without waiting for supplier reports. In some instances, integration of monitoring and the Service Desk to provide an Operations Bridge can enable Service Desk staff to become more pro-active in supplier liason and provide better and more accurate communications to users. Rather than heated 'emotionally' driven service reviews, meetings become more objective and fact based.

This leads to a vital conclusion that : SLAs should actively seek to include objectively measurable (business based) determinants of success or failure and should use these as the basis of service reporting, service level reviews, service penalties and of contract and service level negotiation.

In order to achieve this it is important that IT (or our intelligent customer function if much of IT is outsourced) represent effectively our business needs, that the 'measurability' of these needs is determined and approaches for measuring these needs directly or 'proxies' for these needs be developed, and that we involve the legal and contracting team early in order that our contracts are built around our SLA and that we don't simply append the SLA as 'Annex A' to the contract and hope for the best.

Intelligent Customers should develop effective measures of Service Quality and implement ongoing monitoring solutions and reporting systems to record performance and to objectively identify failures and degraded service and to correctly assess the SLA and contractual implications of Service Quality.


Technorati Tags: ITIL , Service Management , Best Practice , Service Delivery , Service Level Management , Service Level Agreement

Going Live : Handover to Operations

The project's finished, or is it?, after the last few hectic weeks of issue resolution, bug fixes and the inevitable compromises with the main contractor, internal staff and perhaps third party suppliers the new system (whatever it is) has 'gone live'. Perhaps a relieved director and client account manager, desparate to return to their day jobs have even signed off the go-live and user acceptance testing ("UAT") milestones, perhaps the switch has even been metaphorically or physically flipped.

A tight, Prince2 project management approach was adopted and all of the outstanding 'critical' issues from the project issues log have been resolved, worked-around and perhaps the odd one deferred or 'fudged' to meet the deadlines. The project board has signed off on the project risk register and there was even time to complete three complete cycles of UAT, to 'dummy run' in one key department for a week, even non-functional testing has been completed allowing us to relax a little with regard to scalability amongst other things.

The project manager looks relaxed now, less than a week ago it looked like he hadn't shaved for a week, certainly hadn't seen a barber in more than a month and had forgotten where his tie, and perhaps even his suit trousers were at around about the same time. Our project manager was hands on and had pulled out all of the stops to 'go-live' on time. Now it's done, one last set of Prince2 milestones, Closing the Project (CP), it's as simple as that ...... isn't it?

Often the rush to 'meet the deadlines' both the supplier and the customer's operational teams are more aligned than they might ever have hoped, there is a singular vision and a common goal, to get the system live. Respective motivations may vary, the client department and project team desparate to meet deadlines, to support the organisation, to 'deliver', proving that complex projects can be delivered on time; the supplier may be more motivated by achieving the milstone which probably has a significant payment milestone associated with it in the contract. Sounds perfect, it might be observed, a working harmony of business and commercial interests?

The 'final push' is an essential and undocumented (at least in the majority of the best practice process texts) phase (sorry ... 'stage') of any project, the risks creep in where the focus is on the 'go-live' milestone rather than the project closure objectives. Deep in the Prince2 process, under Closing a Project sits:

• Confirm that maintenance and operation arrangements are in place (where appropriate)

This is where the essential, and often overlooked aspects of the 'Handover to Operations' are verified. Too often this essential stage of the project is overlooked during planning, and perhaps even the work-products required to complete the handover are ommited from the project plan. As a result, it is often at the last minute that operational details apparently unimportant to 'go-live' are rushed through. ICT Infrastructure Management are all too used to hearing, "The supplier just needs to .....", usually followed by one of a large list of commonly missed operations details:

• .... talk to someone about the backups.
• .... get someone to setup remote support/the firewall/a VPN.
• .... chat with someone about the service continuity plan.
• .... explain to someone where the log files are posted and what to watch out for.
• .... arrange for the nightly 9999TB network batch transfer of very important data.
• .... explain the monthly/weekly/daily/hourly!! maintenance tasks.
• .... talk to someone on the *nix/Windows team about integrating user authentication or provisioning an account for all of our 20,000 users before next week.
  

It is often at the sime time that a similar conversation has just been started with the Service Desk Manager, or worse that the Service Desk Manager is overheard quietly asking someone near the water-cooler "This new whizzBang 9000 system that we're getting next week, sounds exciting - do you think it'll have any effect on us on the Service Desk?, do you think we need to know anything about it?".

To avoid these and other common handover failures it is essential that projects consider the needs of Operations and the Service Desk early and in detail with as much vigour and involvement as they should involve Capacity Management, Availability Management and IT Service Continuity Management.


Technorati Tags: ITIL , Service Management , Best Practice , Infrastructure Management , Prince2 , Project Management

Release Management Woes

Somewhere in the world, someone has the perfect testing process. The nirvana of Application and Release Management where bug free software and ultimately a bug free final system is shipped to the marketplace.

So after my somewhat improbable dream, I am brought abruptly back to the reality of this week. As the Chief Technology Officer for a software company I spend much of my life with the work of prioritising bugs (issues), dealing with users discovering undocumented features, some of which might be issues and dealing with the wonders of release planning and scheduling.

So why have I been thinking about Release Management, you might ask? At IXIF we specialise in working to assist clients with the Service Level Management, Availability Management, Capacity Management and Operations Management of their ICT environments. In the past few weeks I have been working with a number of clients many of whom who have had some real, and present problems caused by either their own or suppliers Release Management processes. Too often IT professionals see Release Management as an overhead that is preventing them from shipping product, releasing patches or replacing faulty or out of date equipment quickly. I often hear that the 'process' is delaying staff in 'helping' users, but consider the following problems that all too frequently arise.

• Maintenance of a large number of branches and forks in a software project code base without good merge and integration processes between the forks can quickly result in the same errors occurring in multiple instances of the code, a reduction in the quality of the product delivered to clients and increased lifecycle costs for the project as a whole.



• A lack of communication between the testing/qa teams for forked releases can easily result in identical errors going uncorrected in multiple branches of the code. A lack of proper integration and regression can result in lessons leaned and perhaps issues discovered by one client not being reflected for the benefit of others who are in other branches.



• A lack of a 'living' regression test script, constantly updated, so that errors identified in previous versions of a product are not used to generate new test-cases (either unit tests or functional tests) that can be used to check that they do not re-occur in later builds. In fact this is a common problem and a real-world experience within a lot of corporate and public sector clients using custom software products or products with a limited release circulation.

• Inadequate testing of software 'builds' or 'packages' by the 'client' organisation can often result in conflicts between system software or underlying libraries or perhaps errors arrising from specific devices or drivers present in the customer environment but not in the project test environment. These are as much provider 'Release Management' issues as they are supplier issues.

On a positive note, I have been heartened to be playing with VMware's latest Beta release of VMware server. I have long been a fan of virtualisation and the possibility of software teams being able to build, and test in many more environments without the need for lots of PCs running old or different versions of operating systems presents some real advantages.

The possibility of building test images and distributing them to users with VMware player installed provides the real opportunity of involving more staff and users in the testing process with minimal disruption to their use of existing production systems. Think of the advantages for being able to send out the email message:

Dear All,
A virtual machine with the next version of our software is available. Please take a few minutes to test the functions that you use regularly and provide feedback to the release project team as soon as possible. A copy of the standard and regression test scripts is available in the release documentation library for those who have time to undertake further testing. ~ Release Management

Whether we are responsible for a new corporate desktop, a packaged release of a mainstream application or a branched, customer specific release of a specialist product for a particular vertical industry, as ICT professionals we have an obligation to ensure that we follow a well considered Release Management process.

Technorati Tags: ITIL , Service Management , Best Practice , Release Management