Event Listing: IT in the Park 2016

 

Event Listing: IT in the Park 2016

It’s Edinburgh baby! IT500 and Scot-Tech will be hosting Scotland’s biggest ITSM and IT Operations Management conference at Dynamic Earth in Edinburgh this October. This conference will follow previous IT500 & Scot-Tech events such as IT in the park 2015 and the IT500 Learning Conference; both of which gained great acclaim from speakers, sponsors and attendees alike. The 2015 conference had over 200 IT professionals gathered in one place to share ideas, hear case studies and learn about new products and services.

Delegates were a good mix from both public and private sectors. Speakers included the CTO of Arnold Clark, CIO of St Andrews University and senior representatives from Standard Life, the Scottish Government and Fife Council. Over 95% of delegates surveyed post event stated that they intend to return with many indicating that they would also be bringing additional colleagues. The event facilitated great networking opportunities with high levels of engagement and a real buzz. New faces, sparkly new products, case studies and workshops – what’s not to love?

 


Event Highlights

On October 25th 2016 the crack team of IT500 & Scot-Tech will take IT in the Park a step further, adding industry hot topics such as SIAM, DevOps and ITAM to complement their existing core messages around best practice and value driven IT services.  The agenda promises to be exciting and action packed; here is a list of some of the presenters and experts who will be speaking on the day:


Event Break Down

 

WHAT: IT in the Park

WHERE: Dynamic Earth, Edinburgh

WHEN: October 25th 2016

WHO: IT500 & Scot-Tech

HOW TO BOOK: Click Here

ITSM Back To Basics – The Service Catalogue

Introduction

So here’s the thing. I’ve worked in IT forever and in ITSM for over 15 years and it never fails to amaze me how many failed or unused Service Catalogues there are kicking about out in industry. As a consultant I’ve seen and heard horror stories of clients paying upwards of £60,000 for a Service Catalogue they were told would solve all their problems only to be presented with a 2 page spreadsheet listing a few business services at the end of the engagement. As an Irish person who remembers the halcyon days of the Celtic Tiger, I’m calling this the ITSM industry’s very own “ah here” moment.

So what is the Service Catalogue and does it deserve all the hype?  ITIL defines the Service Catalogue as a database or structured document with information about all live IT services, including those available for deployment. The Service Catalogue is part of the service portfolio and contains information about two types of IT service: customer-facing services that are visible to the business; and supporting services required by the service provider to deliver customer-facing services. In other words the Service Catalogue is a menu of all available services available to the business. It also provides the real link between the business and IT; it defines the business processes based on IT systems enabling IT to focus on ensuring those services perform well. Not too scary so far right?

Purpose:

The Service Catalogue has two main purposes:

  1. To provide and maintain a single source of consistent information on all operational services and those being prepared to be run operationally; essentially acting as a menu for the business to order IT services from. An ex collegue of mine (waves to Pink Elephant UK) used to say that the first rule of ITSM is “always make it easy for people to give you money” aka the Hubbard – Murphy law of ITSM. How can we make it easy for customers to give us lots of lovely money? By giving them a sparkly menu of course.
  2. To ensure that it is widely available to those who are authorised to access it; in order to be effective the Service Catalogue needs to be front and centre of your IT operation so that it’s used consistently. Let’s think about it logically for a moment, if it’s not being used by the business, then what value is it adding? Exactly.

Scope:

The scope of Service Catalogue Management is to provide and maintain accurate information on all services that are being transitioned or have been transitioned to the production environment ie anything that’s live or about to be very shortly.

Value to the business

  • Provides a central source of information about the IT services delivered by the service provider organisation.
  • The Service Catalogue maintained by this process contains:
    • A customer-facing view of the IT services in use
    • A description of how they are intended to be used; in clear business centric language; there’s a time and a place for technical jargon and the Service Catalogue isn’t one of them. et’s not frighten the horses here.
    • A list of the Business processes they enable (this should be fron and centre – remember – make it easy for people to give you money, right?)
    • A description of the levels and quality the customer can expect for each service, preferable one that links to the appropriate SLA, OLA or contract.

Different Views

  • The Business Service Catalogue  – This contains details of all IT Services delivered to the Business (in Business language and available to the Business if required). The Business Service Catalogue should contain the relationships with business units and business processes that are supported by each IT Service. Typically these are in the forms of Service Level Agreements (SLAs).
  • The Technical Service Catalogue – This expands the on the Business Service Catalogue with relationships to supporting services, shared services, components and Configuration Items necessary to support the provision of services to the Business (typically this is an internal document so it’s not available to the Business). The Technical Service Catalogue focuses internally on defining and documenting support agreements and contracts (Operational Level Agreements and contracts with external providers or third parties).

 

OK, so that’s the basics covered, come back soon for our top tips on implementing a Service Catalogue successfully.

 

Image Credit

Supercharging Your Service Delivery Using SIAM

The lovely people at Cherwell invited me to join one of their webinars to talk about SIAM so here is the link to the recording!

My session was all about how ITIL and SIAM can be used to take your service provision from good to “let’s rock this!” The world and its mum knows that ITIL is the globally recognised framework for ITSM best practice but in a world where outsourcing, co sourcing and multi sourcing models are being more and more common, ITIL alone can’t cope. Enter SIAM; the framework that enables an organisation to manage their service providers in a consistent and efficient way, making sure that performance across a portfolio of multi-sourced goods and services meets user needs. In other words, SIAM is a flavour of ITIL that supports organisations in managing multiple suppliers whilst keeping the user experience seamless for the rest of the business.

We all know that ITIL is inherently all about continual service improvement and a SIAM environment is no different. That said, here are some of the things to look at when looking at SIAM:

Span Of Control

How many vendors can you manage without things being missed, balls being dropped or angry mobs turning up at your door? Look at your span of control and if your numbers of suppliers, partners and vendors is increasing faster than you know what to do with, look at introducing the lead vendor concept to regain some control. Lead vendors.

Understand Vendor Dependencies

However many suppliers or partners you use, the buck will always stop with you from the perspective of the business if something goes wrong. Map out your IT services, how they support business outcomes and which supplier delivers each IT service. The CMDB or a technical view of the Service Catalogue will help you to do this and will enable you to spot any areas of vulnerability so you can plan accordingly.

Organising For SIAM

When preparing for a SIAM environment; having a strategy is key to ensure that you have a holistic view of your end to end service, making sure nothing is lost or missed. This strategy should be used as the basis for policies, procedures and work instructions to ensure that there are consistent ways of working across the board. Each vendor should have a catalogue of service offerings to ensure dependencies are identified and documented.

Relationship Management

An effective SIAM environment is all about the relationships between the customer organisation and its partners. Moving to a SIAM model will require a culture change so building a collaborative culture is vital. One way of nixing a blame culture is to use the practice of unconditional positive regard (UPR). UPR is a term credited to humanistic psychologist Carl Rogers and means accepting and respecting others as they are without judgment or evaluation i.e treating everyone with the best of intentions. If all else fails, there might be another term that works – TCB or tea coffee and biscuits!! The overall aim? There’s no more “them” and “us”, there’s simply one team.

Managing Performance

As with the span of control, the more SLA, OLA and Contract documentation you introduce into your process, the more admin is required and the more difficult it is to keep things under control. One solution is to have a shared service level agreement across all vendors to cover the end to end service which will encourage collaboration and reduce any potential blame culture. Measurements should be based off this single SLA to communicate how processes are performing, identify any improvement areas and to demonstrate that improvement is happening.

Tools

The ITSM tool industry is moving to support SIAM environments. Out of the box integrations, codeless functionality and add ons are all available in the market giving customers options.

Benefits

  • A single point of contact, ownership & control for IT Services
  • Clearly defined roles & responsibilities
  • Optimised cost of services
  • Streamlined management of IT services
  • Consistently applied processes
  • A more transparent IT landscape
  • Increased Customer Satisfaction!

Did you listen to the webinar? Let me know what you thought in the comments!

Image Credit

Batman, SIAM and Mean Time Between Ass Kickings: SITS16 Recap

It’s the London Olympia baby! Last week was the 2016 Service Desk & IT Support Show or SITS for short. SITS is a annual, free event in central London dedicated to all things tech support and ITSM related.

 

DevOps Needs Leaders – Daniel Breston

The first session we attended was run by fellow Batman super fan and all round ITSM rockstar Daniel Breston.

 

 

Taking all of 5 seconds to get a Batman reference into his content, this was clearly destined to be my favorite session of the day. Daniel opened by talking about the iceberg of ignorance, in other words, the further away you get from service delivery, the few problems that you see. Daniel continued by discussing how one of the biggest challenges faced by managers is taking the time to improve.

Daniel introduced the ITIL, Agile and Lean triumvirate explaining how it’s not enough to have best practice, we must be responsive to the needs of the business and efficient in the way we deliver enterprise services.

The next part of Daniel’s presentation focused on how DevOps is a way to do better faster safer on a continual basis. Daniel talked about the need to focus on the entire value stream of better faster safer from strategy right through to operations.

Daniel went on to talk about measurements and advocated putting your business reports in a language your company understands for example from zero to we got this! He also introduced a brand new metric which I think our friends at AXELOS towers should be all over in terms of including it in the next ITIL refresh.

The final part of Daniel’s session focused on behavior. As Daniel put it “DevOps starts with management talking to people and finding out what their problem are.” Daniel talked about the 3 ways to manage effectively environment:

  • You built it, you run it
  • Project to product
  • Strangle the complexity – lose the nonsense

His final point? Don’t forget to celebrate your successes along the way, preferably with beer!

The Pros and Cons of Public and Private Cloud – Sarah Lahav, SysAid Technologies

 

Sarah opened her session by talking about the recent LinkedIn hack; asking her audience how many of them were able to understand if their personal data had been compromised from the e-mail response issues by LinkedIn – ie the importance of asking the right questions.

Sarah went on to talk about the public cloud and private cloud and the pros and cons of each approach. Public clouds are typically easy to use, flexible and operated by a third party but may be unreliable and less secure than an in house solution. Private clouds are organisation specific, customisable and more secure but can be more costly and require in house expertise.

The next part of the session looked at how a hybrid model can give organisations the best of both worlds without increasing risk. Sarah went on to talk about case studies of the SysAid product from General Cable. Fluortek and LAN Airlines who has the impressive statistic of being able to handle seven times the number of Incidents since using SysAid.

Sarah concluded by explaining with the evolution of SaaS and cloud, it takes new skills to manage your estate effectively, Sarah’s advice? Every organisation is different so in terms of cloud provision, capture the requirements of your organisation and then plan accordingly.

 

Transforming The Service Desk With SIAM & Lean – Joe Bicknell, ServiceNow

The final session we attended was Joe’s session on Service desk transformation. Joe opened with the frankly terrifying statistic of outside the workplace, 84% of requests are automated, inside the workplace only 33% of requests are automated. The upshot? The average employee spends around 15 hours of their working week faffing about trying to  battle the admin mountain.

 

Joe went on to explain the ServiceNow way of thinking “we believe everyone in your organisation requests something and everyone in your business is a service provider in some way.”

 

Joe used ServiceNow to demonstrate how ITSM can be applied to the entire organisation, streamlining processes and removing silos. His top three takeaways?

 

  • Own IT Service Management in your business; it’s the key link between the front and back office.
  • Change the way you work, don’t use technology to compliment what you do
  • Take the workshop to your organisation and start to take Service outside of IT

 

Did you go to #SITS16? Let us know in the comments!!

 

Image Credit

IT500 Conference: DevOps – Bring IT Out Of The Shadows

I caught up with Daniel Breston ahead of tomorrow’s IT500 conference in Edinburgh to talk about his session with Helen Beal.

Daniel BHelen B

The session will involve Daniel and Helen working with the audience to figure out what good looks like and how to develop a culture of sharing and collaboration. Delegates will take away a chart of behaviours from zero to “let’s do this”. The session will focus on how to use the principles of DevOps to deliver real value to your organisation, as Daniel put it “In DevOps you know you are having a good day when you are enabling business objectives”.

You should attend this session if:

You would like to find out more about DevOps and practical tips on how to get started.

The official bit:

One of the biggest threats to organisations today in unmanaged technology. Shadow IT, technology solutions not meeting business needs, performance indicators not driving behavioural change, knowledge not being shared and automation capabilities being misapplied. What would happen if you had a way of going from idea (strategy) to realisation based on a communicative, collaborative and improving culture? This is DevOps, a mindset using technology to define “great” removing business obstacles and enabling goals on a daily basis, top down. Learn how to apply the principles of CALMS (Culture, Automation, Lean, Metrics & Sharing) to create sustainable development, delivery and improvement.

 

For more information, check out this link.

 

Image Credit

Guest Post: Practical ways to end the DevOps – IT Service Management Stand-Off

There’s some great dialog in the final standoff between Batman and the Joker in the movie The Dark Knight. It’s no-rules anarchy versus incorruptibility – “this is what happens when an unstoppable force meets an immovable object”- as the Joker maniacally puts it.

6013651966_65c232e9f8_b

In some ways it’s analogous to the friction existing between development and IT service management (ITSM) – especially how each group views DevOps. If you ask each team what DevOps means to them you’ll probably get two different answers. On the one hand, developers may stress freedom of action and faster releases, while on the other, ITSM practitioners might say DevOps changes nothing. After all, processes and controls painstakingly developed over many years is the ‘tough love’ needed to ensure regulatory compliance and address many other governance related issues.

Unstoppable force meets immovable object

Some ‘modernists’ will of course argue that old-style ITSM can be excluded from DevOps initiatives. After all, it’s a set of practices designed for a style of business computing where risk tolerance was low. So armed with new terms like lean, agile and fail-fast, it’s a case of get with the program or get out of the way. Well good luck with that, because without recalibration, those traditional incident, problem, change and release management contact points between development and ITSM will become even more abrasive. So enrolling the support of existing ITSM roles and practices is critical; turning naysayers and opponents into advocates. But this isn’t going to be easy and requires some deft organizational footwork. If everything remains equal nothing will change In order to remove friction, DevOps leaders should start by clearly communicating why it’s necessary to change. Care should be taken to avoid over hyping DevOps; preferring instead concise explanations as to why the change is occurring in the context of business impact and outcomes. During this early stage it’s also important to set a collaborative foundation; giving strong consideration to temporarily seconding key ITSM influencers to the DevOps program so as to build trust.

In many industries, computing controls, especially in areas such as change and release management, exist to ensure compliance with regulatory mandates. To development these appear cumbersome, but have been specifically designed to mitigate risk – even if that means slowing down processing. Furthermore, these controls deliver auditable proof that compliance procedures are being followed. The problem is that many of these controls might be too rigid to support development projects where risk tolerance is higher, so it’s critical for teams to optimize or right-size sets of controls for specific use cases. Here, care should be taken not to abrogate risk responsibilities by simply passing control ownership (for example, enabling development managers to approve changes but still carry all auditing responsibilities), since that might lead to increased friction and resistance to change – where you least want it – within the development group itself.

In terms of optimizing existing (but necessary) controls, this could involve enacting faster and more reliable ways to meet compliance requirements. For example, employing automated test suites during the actual development process – versus having auditing ‘gatekeepers’ come in at the end of the process and discover the system isn’t compliant.

In God we Trust – everyone else brings data!

Organizations have usually made a significant investment in IT service management tools. These tools, especially the knowledge bases supporting processes like incident, problem and change management can provide teams rich sets of information to drive DevOps improvements. Change records correlated with performance-related incidents and problems could help teams focus on non-functional aspects of development and testing requiring attention. Additionally, emergency change procedures could be reviewed to determine their applicability in supporting business-critical or urgent software updates. In all cases, however, teams should ensure flexibility doesn’t increase business risk – for example – by teams choosing the path of least resistance to avoid governance scrutiny. There are many other ITSM contact points teams can review to reduce friction. In incident management developers often complain that it takes too long for them to be notified of problems related to their code – only after lengthy level 1 and level 2 operations review. This causes friction because developers might be taken off projects to fire-fight problems that due to time delays have become more complex to diagnose and remediate.

To address this, teams should carefully review notification procedures; perhaps even changing the first point of escalation to be the development group responsible for the application or service – even after hours. Expect push-back where you least expect it. Developers may resist mandated on-call support. Therefore it’s important to impress how their early involvement in incident response is critical to drive improvements. It’s also a good idea to equip them with analytic tools and proactive methods that help them resolve complex and emerging issues. Finally, an important, but often understated bi-product of this ‘skin in the game’ approach is developers working to improve the ongoing supportability of applications. For example, it could result in improving documentation and fault logging so they only need to be called in when absolutely necessary.

Ignoring the points of friction between DevOps and older (but still important) ITSM processes will cause initiatives to stall or fail. The only way to ensure success is when teams put all governance and risk-versus-speed and agility concerns on the collective table and enact improvements in the context of required business outcomes. Always consider that without constant engagement, staff on both sides will revert to sub-optimal practices – the ones that stifle innovation or carry huge risk.

PW

This article was contributed by Peter Waterhouse, Senior Strategist, CA Technologies

Image Credit

IT500 Conference: Introducing a CSI Sat Nav

Ahead of the IT500 Conference in June, I was lucky enough to speak to presenters Ian MacDonald and John Griffiths and discussed their workshop: “Introducing a CSI Sat Nav”.

Ian&John


Their session will explore why CSI is so critical to drive success and how to focus on the improvements that will make the most difference.

The workshop will look at how to get CSI going in an organisation, things people can do in the workplace to facilitate a CSI culture, scope setting and empowering people so that they can be advocates for improvement. The sat nav analogy will be used to explain the 6 step CSI model:

  • What is the vision?
  • Where are we now?
  • Where do we want to be?
  • How do we get there?
  • Did we get there?
  • How do we keep the momentum going?

You should attend this session if:

You would like advice on getting started, you’re interested in CSI or you’re looking for guidance and new ideas.

The official bit:

‘In this session we introduce the concept of the CSI sat nav and how it can be used to positively engage and motivate your team. With the competing demands of time and resource, we look at where we should actually target our improvements to actually deliver value to the business. Using the ITIL CSI model, we will show how to baseline current performance and measure ‘what good looks like’’.

 

Are you going to IT500? Let us know in the comments!

 

Image Credit

Agile, DevOps, ITIL & Buzzword Bingo; BEYOND20 SIXTEEN Podcast

We are pleased to share our very first podcast on the BEYOND20 SIXTEEN conference next month.

 

I spoke to conference rockstars David Crouch and John Gilmore about life, the universe, ITIL, Agile and DevOps!

David-Crouch-Headshot-262x272
David Crouch
Gilmore400-1-262x272
John Gilmore

David’s session is: ‘The pros and cons of adhering to a single best practice framework – tales from the trenches‘ and John’s session is about integrating SDLC, DevOps & ITSM so between the two of them, there was a wealth of experience on the line.

Some of the things we talked about were traditional versus Agile approaches, closed loop models and how ITIL has evolved over time.

 

 

 

You can listen to the podcast on SoundCloud.


 

Who and what would you like to hear on future podcasts? Please get in touch and let us know – Drop us a line, send us a Tweet, leave a comment on this blog post or post ideas on our community forum. Thanks.

 

BEYOND20 SIXTEEN Image Credits

The DIKW model for Knowledge Management

Following on from last week’s article about the advantages of Knowledge Management and how to get started, let’s look at the process in more detail. When I’m running ITIL foundation courses I generally hit Knowledge Management as part of the Service Transition stage of the lifecycle towards the end of day 2. Put yourselves in the shoes of the poor delegate for a second and think after 2 solid days learning about 20 odd processes and 4 functions even the brightest person in the room is starting to get a bit tired of all the terminology. To try and fix that; here’s my handy guide to Data Information Knowledge and Wisdom aka the Dick Whittington model for Knowledge Management.

DIKW

Data

First up we have Data. No, not the character from Star Trek TNG (although – spoiler alert – I’m still heartbroken by the ending of Nemesis) but the facts and figures which relay something specific. ITIL describes data as a discrete series of facts about events. When we talk about data; it’s raw in format, not organised in any way and providing no further information regarding patterns, structure or context. Data represents singular facts or numbers but by themselves, data items have little meaning.

The key Knowledge Management activities include:

  • Capturing accurate data
  • Reviewing data and adding context so that it can be transformed into information
  • Ensuring only relevant data that adds value is being captured as lets face it, anything else is just noise.

Information

Data becomes Information when it can be viewed in a specific context. According to ITIL, for data to become information it must be contextualised, categorised, calculated and condensed. If data is a series of facts, information is generally stored in some sort of structure for example, e-mails, documents or spreadsheets.

The key Knowledge Management process around information is managing the content in a way that adds value. In other words, ensuing information is easy to capture, query, find, reuse and re learn from experiences so we don’t keep making the same mistakes and duplication is reduced.

Knowledge

For information to become knowledge it must be processed organised or structured in some way, or else as being applied or put into action. Knowledge combines information with experience and can be used as a basis for decision-making or taking an action. Knowledge is made up of the experiences, ideas, insights, values and judgements of your people. When we introducing formal Knowledge Management; creating the right culture is absolutely critical so that people feel comfortable adding to Knowledge Bases and articles ensuring the right knowledge is captured. Done well, Knowledge Management will engage and up skill your people so it really is worth focusing on.

Wisdom

Wisdom is the trickiest stage to explain. ITIL defines wisdom as being the ultimate discernment of the material and having the application and contextual awareness to provide a strong, common sense judgement. I’ve been in IT long enough to realise that you can’t teach common sense but by having the right training and support in place goes a long way to avoid a herding cats situation.

My favourite way of explaining Wisdom to ITIL foundation delegates is this example from Irish legend Paul Howard (author of the Ross O’Carroll Kelly books)

In all seriousness though, by applying Wisdom, you have the ability to increase effectiveness. It’s the value add based on being able to improve accuracy, drive efficiency and support CSI.

So that’s the basics to the Data Information Knowledge Wisdom model, what do you think? Let us know in the comments!

 

Image Credit

 

 

Configuration Management How To (Part 2)

Following on from our previous article, this week we’ll take a look at Configuration Management baselining and control.

Configuration Baselining

2561885967_f5f0be5834_z

First up we have the identification or baselining step in our Configuration Management process. This is a baselining process, taking a snapshot of our critical services and their key dependencies so that we know exactly what makes up the service. The purpose of a baseline is to take a measurable part of the service so that it can be added to a CMDB (Configuration Management Database) or CMS (Configuration Management System). As it’s a snapshot of the state of a service at a point in time, it can be used as part of Change Management as if the service has changed there will need to be a valid, authorised RFC against it as well as being a stable reference for future planned works.

So how do you carry out a baselining exercise in real life? My advice? Start with your most critical service. You know the one. The system that if there is even a hint of slowness or performance issues your Service Desk is inundated with calls and the angry mob are off out finding their flaming torches and pitchforks. That’s the one. Start by talking to everyone involved with the service from support teams to the business. If it requires third party support, consider asking your supplier for their guidance for what data should be captured in a CMS for example if you ever need to log a support call with them, what are the top ten things they will ask for?

Don’t try to capture too much data at first – you can always build things up later but if you try to go into too much detail when starting out you might run out of time and money. Also bear in mind, the more detail you capture, the more work it will be to maintain. As a starter for ten, here are some useful CI attributes to capture:

  • Unique Identifier
  • CI type eg server, network device, software package
  • Version Number
  • Support Details
  • Vendor Details
  • Licence Details
  • Purchase Date
  • Owner
  • Location
  • Warranty Details
  • Relationships to other CIs

You also don’t necessarily need an expensive tool – I used to work for a small bank during its UK start up and the IT budget was really tight. We desperately needed a CMS to support Incident and Change Management but didn’t have a tool. I went round to every support team and techie I could find and used a spreadsheet to build up a basic CMDB of our key services then created a business case over the following few months to demonstrate the benefits (I was able to demonstrate tangible reductions in Change failures and Incident resolution times) to secure funding for an ITSM tool that included a CMDB.

Remember any CMDB, no matter how basic, is better than nothing. If you are going down the spreadsheet route then talk to your techies. If discovery tools such as SMS or Alteris are in place then they could be used to help you build a basic CMDB.

Configuration Control

3812759931_8aa94e57bb_z

Configuration Control goes hand in hand with Configuration identification and baselining. Having control in place means that there is appropriate support in place to ensure that when a CI (Configuration Item) is updated, that the CMS is updated so that what you have in the CMS matches exactly what you have in your production environment. Nothing will make your Configuration Management process fail quicker than your CMS having incorrect or out of date information so control is a critical aspect of Configuration Management.

Work closely with Change Management to make sure your processes are aligned; for example you could put a process step in place where a Change can only be closed off as successful when the CMS is updated. Sounds basic I know but you would be amazed at how many times I’ve seen people forget to update documentation following Change activity so if you have it formally built in to the process, nothing can be missed or forgotten about. Also, if you’re not part of the CAB meeting, get yourself invited so you can add subject matter expertise around service relationships and dependencies during impact assessments.

Work with Change Management to consider putting Change freezes in place during key process points such as baselining or audit exercises so you’re not trying to hit a moving target. Believe me, there is nothing more stressful in an audit situation than having a last minute panic about the version information of a CI being up to date following a Release the previous night.

These are our top tips for Configuration baselining and control. What do you think? Let us know in the comments!

 

Image Credit

Image Credit