Knowing what you DON’T know

Question Mark

I presented an Asset Management breakout session at the BMC Engage conference in Las Vegas today.  The slides are here:

An interesting question came up at the end: What percentage accuracy is good enough, in an IT Asset Management system?  It’s a question that might get many different answers.  Context is important: you might expect a much higher percentage (maybe 98%?) in a datacentre, but it’s not so realistic to achieve that for client devices which are less governable… and more likely to be locked away in forgotten drawers.

However, I think any percentage figure is pretty meaningless without another important detail: a good understanding of what you don’t know. Understanding what makes up the percentage of things that you don’t have accurate data on is arguably just as important as achieving a good positive score.

One of the key points of my presentation is that there has been a rapid broadening of the entities that might be defined as an IT Asset:

The evolution of IT Assets

The digital services of today and the future will likely be underpinned by a broader range of Asset types than ever.  A single service, when triggered, may touch everything from a 30-year-old mainframe to a seconds-old Docker instance. Any or all of those underpinning components may be of importance to the IT Asset Manager. After all, they cost money. They may trigger licensing requirements. They need to be supported. The Service Desk may need to log tickets against them.

The trouble is, not all of the new devices can be identified, discovered and managed in the same way as the old ones.  The “discover and reconcile” approach to Asset data maintenance still works for many Asset types, but we may need a completely different approach for new Asset classes like SaaS services, or volatile container instances.

The IT Asset Manager may not be able to solve all those problems.  They may not even be in a position to have visibility, particularly if IT has lots its overarching governance role over what Assets come into use in the organization (SkyHigh Networks most recent Cloud Adoption and Risk Report puts the average number of Cloud Services in use in an enterprise at almost 1100. Does anyone think IT has oversight over all of those, anywhere?).

However, it’s still important to understand and communicate those limitations.  With CIOs increasingly focused on ITAM-dependent data such as the overall cost of running a digital service, any blind spots should be identified, understood, and communicated. It’s professional, it’s helpful, it enables a case to be made for corrective action, and it avoids something that senior IT executives hate: surprises.

Question mark image courtesy Cesar Bojorquez on Flickr. Used under Creative Commons licensing.

Advertisements

Thoughts on #cfgmgmgtcamp, and why ITSM needs to take note

Configuration Management Camp logo

Mention the role of “Configuration Manager” at an ITSM conference, and then use the same description at an Infrastructure Management conference, and your respective audiences will visualise completely different jobs*.

So, it was with some curiosity that I arrived this morning for the first day of the Configuration Management Camp in Ghent.

This particular event falls squarely into the infrastructure camp. It’s the realm of very clever people, doing very clever things with software-defined infrastructure. A glance at the conference sponsors makes this very clear: it includes Puppet Labs, Chef, Pivotal, and a number of the other big (or new) names in orchestrated cleverness.

While this is not the ITSM flavour of Configuration Management, however, today’s conference really made it clear that this new technology will become more and more relevant to the ITSM community. In short, ITSM should make itself aware of it.

The tools here have underpinned the growth of many recent household-name startups: including those internet “unicorns” like Facebook and Uber which have risen from zero to billions. They’ve enabled rapid, cloud-driven growth in a brand-new way. This new breed of companies have firmly entrenched DevOps methodologies, with ultra-rapid build, test, and release cycles, increasingly driven by packaged, repeatable scripts. It primarily takes place on cloud-based open-source software stacks. As a result, there’s not quite as much focus on resource and commercial constraints as we find in big enterprises.

But here’s the crux: methods like this will surely not remain solely the preserve of the startups.  As business get deeper into digital, there’s increasing pressure on the CIO from the CEO and CMO, to deliver more stuff, more quickly. As the frontline business pushes its demands onto IT, long development and deployment cycles simply won’t be acceptable. And, with equal pressure on IT’s costs and margins, these technologies and methods will become increasingly attractive.

Rapid innovation and deployment is becoming essential to business success:  PuppetLabs 2014 State of Devops study recently claimed that strongly performing organizations are deploying code 30 times more often, with 50 times fewer failures. Okay, those numbers come from squarely within the Devops camp, but they are credibly reinforcing past analysis such as MIT Sloan’s 2007 classic study on “the alignment trap”. IT can’t just be a ponderous back-end function if a company wants success.

That’s not to say that this conference is providing the answers. I’d argue that Configuration Management Camp is the “bottom up” conference to an ITSM conference’s “top down”.

Some of the toolsets on display here are very granular indeed. Many of the presentations were slides, or live demos, full of slightly arcane command-line-interface text input. We watched individual clusters get provisioned, quickly, impressively, but devoid of context.

However, there was also a sense of an increasing imperative to start connecting those dots: to define the applications and their inter-dependencies, and ultimately, the services. We’ve seen talks today with titles like “Configuring Services, not Systems”. Dianne Mueller of Red Hat OpenShift described new tools which focus on the deployment of applications, rather than points of infrastructure.

I spoke with more than one person today who described DevOps starting to meet “reality” – that is, the day-to-day expectations of an enterprise environment.  There is a feeling of “cutting edge” here, probably justified, but the counterpoint to that might be that this community tends to see “traditional” IT is seen as slow and clunky.  PuppetLabs founder and CEO, Luke Kaines dismissed this: “The enterprise space doesn’t move slowly because they’re stupid or they hate technology. It’s because they have… what’s the word… users”.

One thing that was clear today was that these technologies are only in their infancy. Gartner recently identified Software Defined Infrastructure as one of its key trends for 2015. Forrester have declared that Docker, the rapidly-emerging containerisation technology, will “live up to the hype and rule the cloud”.

And that’s why IT Service Management needs to take note.

We can’t understand the services we provide our customers, if we don’t have a grasp on the underlying infrastructure. We can’t formalise change control without getting the buy-in of the technical experts for whom rapid infrastructure shifts are a command-line prompt away. We can’t help prevent uncontrolled software spend, or inadvertent license breach, if we don’t proactively map our contracts onto the new infrastructure. With change cycles moving from weeks to seconds (it was claimed today, in one session, that Amazon deploys code to production on a sub-one-second interval), established ITSM practices will need to adapt significantly.

So, if it feels like ITSM’s “top-down” and infrastructure configuration management’s “bottom-up” are striving to find a connection point, it also feels like that join has not yet been made. It’s up to IT as a whole to make that connection, because if we don’t do it, we’ll end up repeating the lessons of the past. But faster.

It’s going to be a fun challenge to face. This is exciting stuff.

*ITSM: defender of the CMDB. Infrastructure: server deploying and tweaking wizard. Right?

Mobile ITSM isn’t only about field support: It’s about everyone.

iPhone 6

When we built the new Smart IT UX for BMC Remedy, we were determined to allow ALL IT Support Workers to be Mobile. Why? Because everyone can benefit from mobility.

In the short history of enterprise mobility, mobile business applications have generally focused on two specific user groups. The first is the group of users for whom being on the road is the bulk of their job, such as field engineers: they go to a location, perform some tasks, move on to the next place.

The second group is those who might be based at a desk in an office, but who move around through a series of meetings, on and off-site. For these users, the primary purpose of mobility has been continuity of communication (with the weapon of choice having historically been the keyboard-equipped Blackberry).

For most other users, performing most other business tasks, the desktop computer (or desk-based notebook computer) still remained the key delivery mechanism for business applications.

Today, this is an outdated philosophy.

I recently stood in a lift at a customer’s office. There were four people in that elevator, and there were seven smartphones on display.  Okay, two of them were mine (I’m a mobility product manager, after all), but that is still a notable average.

Even in the short moment offered by a journey of just a few floors, those office-based employees found a moment to communicate. Whether that communication was work-based or personal, one-way or two-way, is irrelevant. The point is that the time was being used to perform those tasks in a way that could not have happened just a few years ago.

In the December 2014/January 2015 edition of Fast Company, Larry Erwin, a Business Development Executive with Google, points out:

“When I was a kid growing up back in the ’90s, I was the only kid on my block with a Tandy 1000. Now kids who are 15, 16 years old have a supercomputer in their pocket”

The opportunity for business software tools to take advantage of that new computing power is huge, and growing. The very structure of the traditional office is under pressure, as users become more mobile and more technology enabled. That generation of teenagers will soon enter the workplace having had a completely different, and more universal grounding in technology than we select geeks who owned the Tandy 1000s and Sinclair Spectrums of yesteryear.

Mobility has already become a primary means of service consumption for customers, across a swathe of industries. Consider the process of taking a flight: with many airlines, the entire customer experience has been mobilized. Forrester Research outlined this beautifully in a 2014 illustration charting the timeline of mobile engagement for the airline passenger:

  • -2 Weeks: Book ticket, change reservation
  • -2 Days: Change seat, request upgrade
  • -2 Hours: Check in, check gate, departure time, lounge access
  • Flight: Arrival time, food order, movies, wi-fi, duty free
  • +2 Hours: Ground transport, lost luggage, navigation
  • +2 Days: Mileage status, reward travel, upcoming reservations
  • +2 Weeks: Mileage points earned, customer satisfaction survey
    (Source: Forrester)

Mobility for the consumer is now table stakes. So why not extend this to the people serving those consumers? Mobility, simply, provides great opportunities to enhance the role of the service representative.

When I arrived at a Westin Hotel in Chicago last month, I needed to speak with reception, and joined the line of people at the check-in desk. However, I was approached by a staff member with an iPad. They were quickly able to answer my question. The Starwood Hotels group, he told me, aims to keep its hotel staff on their feet, closer to customers, delivering service in a more dynamic way. Even the group’s CEO, Fritz van Paasschen, has abandoned his desk and PC: a Wall Street Journal article in November 2014 revealed that he works entirely on tablet and smartphone (van Paasschen’s office contains no desk – just a boardroom table and a couch).

In an IT Service Management environment, the case for mobility for field support users has long been clear: the alternative being a hotch-potch of printed dockets, slow communication, and inconvenient (or omitted) retrospective updates to systems of record, back at a field office.

But even in the office, it’s important to realise that good IT service, like all good customer service, combines communication, expertise, initiative and process. Many people involved in that process are not at their desk all day: they may be in meetings, or travelling between sites, or sitting with colleagues.

If those people can only access their support tools from their desk, then gaps appear. Twenty minutes waiting for input from an approver or technical expert could amount to twenty minutes more waiting time for the customer, or even a missed window to communicate with the next person in the chain (and hence an even bigger gap). Mobilising people – properly – fills those gaps, even in the office. And, as the IT department’s customers get more mobile, the best way to support them is often to become more mobile.

When we built the Smart IT interface for BMC Remedy, released in September 2014, this was the philosophy of our mobile approach: ITSM should be mobile for every user, whether they are field support technicians roaming a wide area, or a service desk agent taking a five minute break at the coffee machine.

The tool needed to provide all the features they need, including comprehensive teamwork features and assistiveness, so that they are never forces to find a desk or wait for the slow boot-up of a traditional PC. We released the tablet version of Smart IT on day one, and the phone version, scheduled to be live in December 2014, has been already received a great reception in demonstrations at customer events. As with Smart IT in general, there’s no additional cost over and above a standard Remedy ITSM license.

Our work with our ITSM customers has shown us, and them, that there are huge and real business benefits to seamless and comprehensive mobile experience. Time not spent in front of a PC no longer needs to be time spent not helping customers.

Properly equipped, an increasingly mobile-focused user base is sure to find those benefits, and that means faster, better outcomes for IT’s customers.

Is the lack of ITSM and ITAM alignment causing application sprawl?

Urban sprawl

I’ve written before about the negative consequences of the lack of industry alignment between ITIL-focused ITSM functions, and the IT Asset Management groups which typically evolved somewhat separately.

A recent CapGemini study of CIOs and IT decision makers concisely illustrated one impact this is having:

  • 48% believe their business has more applications than it needs (up from 34% over the previous three years).
  • Only 37% percent believe the majority of their applications are mission critical.
  • 70% believe at least a fifth of their company’s applications share similar functionality and could be consolidated.

The majority believe a fifth of those applications should be retired or replaced.

This shows a very strong consensus amongst IT leaders: IT is spending too much money and time on too many applications, with too much overlap. And in the rapidly evolving application landscape, this impact is by no means limited to traditional on-premise software: Skyhigh’s 2013 study on cloud service adoption found that enterprise respondents used, on average, well over 500 cloud services (the largest number of services found in one organisation was an eye-watering 1769).[Update for Q1 2015: SkyHigh now put the average at over 900]

If we want to remain serious about understanding the business services our IT organizations are managing, overseeing and underpinning, surely we can’t lose track of key assets like this?

How can IT possibly aim to control this sprawl, understand its impact, pinpoint its risks and and remove its vulnerabilities, if there is no unified overseeing function? Who is tracking which users are entitled to which services? Who ensures that users are equipped with the right services, and who removes their access once they leave, to ensure both data security and cost control? Who can identify the impact on key services if an application is removed or consolidated?

Concerningly, this does not appear to be high on the agenda in ITSM discussions. We still see two separate threads in the conference ecosystem: ITSM conferences rarely address asset management. Asset management conferences talk about suppliers and infrastructure without putting them in the context of the services they underpin. My own role involves product management of an ITAM system which is part of an ITSM suite, so I attend both sets of conferences, see both parallel tracks, and experience nagging concerns in each case that the other side of the picture is overlooked.

Recent initiatives such as the Pink Think Tank 14 are, welcomely, addressing in increased detail the multi-sourced, multi-vendor evolution of IT service delivery, but there still does not appear to be a detailed focus on the actual assets and software being supplied by those vendors.  That’s a gap. Those vendors fill the IT environment with assets, from physical kit through software services to less tangible “assets” like critical people with vital knowledge.  All those things cost money. They may have contractual associations. We may need to know, very quickly, who owns and supports them. And if a supplier is replaced, we need to know what they might take with them.

The harsh reality, as clearly shown by CapGemini’s study, is that CIOs and leaders are asking questions about consolidation that will require a detailed, holistic understanding of what we are actually spending money on, and why it is there.

Some initial thoughts on the Service Management Congress

Having gone away on paternity leave for a few weeks (I’m writing this with a sleeping four-week-old stretched along my lap), I initially missed the fuss that came out of the Service Management Fusion13 conference. On returning, an acquaintance in the UK ITSM sector emailed me and suggested I take a look at the Service Management Congress website, and its bold rallying call:

SMCallAction

That’s quite a lot to take in between sleep-deprived nappy changes, so I’m grateful that he also pointed me to some useful and interesting context from prominent ITSM consultant, podcaster and blogger Barclay Rae:

What I didn’t expect was to be involved in a ‘revolution’, but that happened too…
Over the week – and with the support of the organisers – a number of meetings were held with a cross-section of ITSM people who wanted to see change happen and to do something about it – now. A few people were initially invited and others like me simply joined as part of the conversation . The sessions were originally set up with the intention of discussing how to improve or develop the role of the itSMF (especially in the US) – which (with the exception of some great chapters in northern Europe and elsewhere) is perceived to be flagging. The discussion moved on from that to a bigger and more fundamental view of how to fix the industry – perhaps idealistic but certainly with positive intent.

A post on the SM Congress website itself, entitled  “Background on the Group Formerly Known as RevNet“, detailed the terms of referene that had been given to the core, invited group who had drawn up this fledgeling manifesto:

* To challenge our community of service management professionals to look at things differently and to embrace the future
* To challenge us (itSMF USA, and to a lesser degree, the entire itSMF international community) to improve and stay relevant
* To challenge themselves and explore what should come out of this group – what should come next

This is interesting – a brief to look at things with “a fresh set of eyes”, equivalent in part to the spin-out group described in Clayton M. Chrisiansen’s “The Innovator’s Dilemma”, assembled as an independent, fresh entity to avoid the challenge of responding to disruptive influences from an established, mature and successful market position.

Companies that have tried to develop new capabilities within established organizational units also have a spotty track record, unfortunately. Assembling a beefed-up set of resources as a means of challenging what an organization can do is relatively straightforward… Too often, however, resources such as these are then plugged into fundamentally unchanged processes, and little change results…

A separate organization is required when the mainstream organization’s values would render it incapable of focusing resources on the innovation project.

I’ve signed the pledge. I think the intentions seem very honourable, and the problems identified by the group are real, if somewhat loosely stated. Many of the principles seem spot-on: it’s certainly my view that too much of the information that should help us to drive our industry is hidden behind paywalls and accreditation schemes when it should really be a public resource.  My views aren’t fully formed, but nor by its own acknowledgement are those of the Service Management Congress itself.   It doesn’t seem self-evident to me that this structure will work, but it seems a good thing to explore and develop.  At this stage, I have a few key hopes:

I hope that a broad set of ITSM people are able to feel “ownership”: The initial signers and many of the follow-up pledgers are pretty familiar names within the industry: high-profile bloggers, tweeters, and presenters. It’s an impressive set of names, but we do need to bear in mind Rob England’s astute observation that “there are over two million people with an ITIL certificate. I guess quite a few of them are ITSM practitioners in one form or another – even if they wouldn’t call themselves that – let’s say a million. So a few thousand have read the SMcongress stuff and a few hundred have put their names on it“.  If this is perceived, even if very unfairly, as a talking shop for some “usual suspects”, it won’t get near any critical mass.

I hope we remember that ITSM doesn’t suck!:  There is plenty of room for improvement, but we have great people in this sector, and we’ve build something effective and successful. It needs to grow, and adapt, but that doesn’t mean everything thus far is a mistake.

I hope the approach is outside-in: This is not an “iPad” moment, where (to paraphrase Steve Jobs) we are creating something our customers didn’t even know they wanted. Great practice will come from real life, and there’s plenty of it out there. We can’t design it from scratch in a meeting room. Anyway, I’m a Product Manager, so I have to say this.

I hope that its ideas are genuinely transformative, but I don’t think it needs to create a revolution: ITSM is a mature framework in a rapidly shifting environment. Is ITIL adapting quickly enough to remain a dependent and definitive standard? There’s obviously doubts and concerns about that.

My own view is that our customers have become comfortable and familiar with a set of tools and practices and interactions provided by their consumer technology that has set the bar much higher in terms of their expectations for the workplace. Upstart providers like Uber, who I have written about previously, have taken century-old customer interactions and transformed them to the extent that traditional providers face disruption out of their markets.  Internet-enabled cloud services have taken aspects of technology that were completely within IT’s domain, and offered them to anyone with a credit card.  This presents both a danger of irrelevance, and a gulf in governance, and ITSM needs to address those issues urgently.

If our established frameworks can’t do that quickly enough, we need a rapid innovation.  But is it realistic to change everything? It feels more pragmatic, initially, to find some great ideas that can fold back into the broader ITSM discipline, bringing genuine improvements without trying to eat the whole elephant in one go.  Our stakeholders, to whom this transformation ultimately has to be sold, won’t accept a message that says “everything changes right now”

I hope that we don’t just do this:
XKCD cartoon -
(see also: camel/horse/committee)

I’m looking forward to engaging, and I’m looking forward to watching things develop. It’ll be interesting to revist this subject in a month or so.

itSMF UK and the mysterious case of the missing Asset Managers

logo of the ITSM13 conference

Something is bothering me.

When I first looked at the agenda for the 2013 itSMF UK conference in November, what stood out for me was a glaring omission: where is the IT Asset Management content?

First, let me state: It’s a really good agenda, full of really interesting speakers, and I will certainly aim to be there. I’ve been privileged to work in the the UK ITSM sector for the thick end of two decades, and many of the names on the agenda are people i feel lucky to have worked and interacted with.

If you can, you should definitely go.

However, the lack of any ITAM focus, across more than 40 presentation sessions, is strange. If we want to understand our business services, we have to have a grasp on the assets underpinning them. The nearest this agenda appears to get to that is an interesting looking session on Supplier Management – important, but only part of the picture, and again, something that doesn’t really work without a good knowledge of what we are actually buying.

It took ITIL a while to come to the realisation that an asset is relevant in more ways than being just a depreciating item on a balance sheet, but version 3 finally got there, and then some:

“Service Asset”, according to ITIL v3: Any Capability or Resource of a Service Provider. Resource (ITILv3): [Service Strategy] A generic term that includes IT Infrastructure, people, money or anything else that might help to deliver an IT Service. Resources are considered to be Assets of an Organization Capability (ITIL v3): [Service Strategy] The ability of an Organization, person, Process, Application, Configuration Item or IT Service to carry out an Activity. Capabilities are intangible Assets of an Organization.”

So… we consider our service-underpinning capabilities and resources to be our assets, but we don’t discuss managing those assets at the premier conference about managing the services? More importantly, we offer nothing to its increasingly important practitioners?

As long as ITAM is only discussed at ITAM conferences, and ITSM keeps up the habit of excluding it (this isn’t universal, mind: this presentation by Scott Shaw at Fusion 13 seems to hit the perfect message), then we risk looking disjointed and ineffective to CIOs who depend on the complete picture. To me, that’s pretty worrying.

(Footnote: I did submit a speaker proposal, but this isn’t about my proposal specifically – I’m sure lots of proposals couldn’t make the list)

Why does reporting get forgotten in ITSM projects?

ITSM initiatives often focus heavily on operational requirements, without paying enough up-front attention to reporting and analytics. This can lead to increased difficulty after go-live, and lost opportunity for optimisation. Big data is a huge and important trend, but don’t forget that a proactive approach to ordinary reporting can be very valuable.

“…users must spend months fighting for a desired report, or hours jockeying Excel spreadsheets to get the data they need. I can only imagine the millions of hours of productive time spent each month by people doing the Excel “hokey pokey” each month to generate a management report that IT has deemed not worthwhile”

Don’t Forget About “Small Data” – Patrick Gray in TechRepublic

In a previous role, aligning toolsets to processes in support of our organisation’s ITSM transformation, my teammates and I used to offer each other one piece of jokey advice: “Never tell anyone you’re good with Crystal Reports”.

The reason? Our well established helpdesk, problem and change management tool had become a powerful source of management reports. Process owners and team managers wanted to arrive at meetings armed with knowledge and statistics, and they had learned that my team was a valuable data source.

Unfortunately, we probably made it look easier than it actually was. These reports became a real burden to our team, consuming too much time, at inconvenient times. “I need this report in two hours” often meant two hours of near-panic, delving into data which hadn’t been designed to support the desired end result. We quickly needed to reset expectations. It was an important lesson about reporting.

Years later, I still frequently see this situation occurring in the ITSM community. When ITSM initiatives are established, processes implemented, and toolsets rolled out, it is still uncommon for reporting to be considered in-depth at the requirements gathering stage. Perhaps this is because reporting is not a critical-path item in the implementation: instead, it can be pushed to the post-rollout phase, and worried about later.

One obvious reason why this is a mistake is that many of the things that we might need to report on will require specific data tracking. If, for example, we wish to track average assignment durations, as a ticket moves between different teams, then we have to capture the start and end times of each. If we need to report in terms of each team’s actual business hours (perhaps one team works 24/7, while another is 9 to 5), then that’s important too. If this data is not explicitly captured in the history of each record, then retrospectively analysing it can be surprisingly difficult, or even impossible.

Consider the lifecycle of a typical ITSM data instance, such as an incident ticket:

Simple representation on an incident ticket in three phases: live, post-live, and archives

Our record effectively moves through three stages:

  • 1: The live stage
    This is the key part of an incident’s record’s life, in which it is highly important as a piece of data in its own right. At this point, there is an active situation being managed. The attributes of the object define where it is in the process, who owns it, what priority it should take over other work, and what still needs to be done. This phase could be weeks long, near-instantaneous, or anything between.
  • 2: The post-live stage
    At this point, the ticket is closed, and becomes just another one of the many (perhaps hundreds of thousands) incidents which are no longer actively being worked. Barring a follow up enquiry, it is unlikely that the incident will ever be opened and inspected by an individual again. However, this does not mean that it has no value. Incidents (and other data) in this lifecycle phase do not have much significant value in their own individual right (they are simply anecdotal records of a single scenario), but together they make up a body of statistical data that is, arguably, one of the IT department’s most valuable proactive assets.
  • 3: The archived stage
    We probably don’t want to keep all our data for ever. At some stage, the usefulness of the data for active reporting diminishes, and we move it to a location where it will no longer slow down our queries or take up valuable production storage.

It’s important to remember that our ITSM investment is not just about fighting fires. Consider two statements about parts of the ITIL framework (these happen to be taken from Wikipedia, but they each seem to be very reasonable statements):

Firstly, for Incident Management:

“The objective of incident management is to restore normal operations as quickly as possible”

And, for Problem Management:

“The problem-management process is intended to reduce the number and severity of incidents and problems on the business”

In each case, the value of our “phase 2” data is considerable. Statistical analysis of the way incidents are managed – the assignment patterns, response times and reassignment counts, first-time closure rates, etc. – helps us to identify the strong and weak links of our incident process in a way that no individual record can do so. Delving into the actual details of those incidents in a similar way helps us to identify what is actually causing our issues, reinforcing Problem Management.

It’s important to remember that this is one of the major objectives of our ITSM systems, and a key basis of the return on our investment. We can avoid missing out on this opportunity by following some core principles:

  • Give output requirements as much prominence as operational requirements, in any project’s scope.
  • Ensure each stakeholder’s individual reporting and analytics needs are understood and accounted for.
  • Identify the data that actually needs to be recorded, and ensure that it gets gathered.
  • Quantify the benefits that we need to get from our analytics, and monitor progress against them after go-live.
  • Ensure that archiving strategies support reporting requirements.

Graphs icon courtesy of RambergMediaImages on Flickr, used under Creative Commons licensing.