What does your ITAM Policy look like?

What does your ITAM Policy look like?

My brain was aching trying to think of something new to write about for ITAM in 2023(!) So I thought I would revisit an aspect of ITAM that doesn’t get the attention it deserves:  An ITAM Policy.

ITAM Policy: Before we begin

It might be worth revisiting some guidance that is applicable to ALL policies, before we dive into the specifics of a policy that relates to ITAM:

Know your audience:  Who are you writing for?  What is their likely attention span going to be in regards to this schism of IT?  Brevity is key – my personal recommendation is that you don’t exceed 4 pages of formal text (cover pages, Annexes, distribution lists, etc don’t count towards those four pages).  Also, keep IT acronyms and topic expressions to a minimum:  IT loves a good acronym! But not everyone reading this document will be in IT.  If you do have to use an acronym, then have the courtesy to provide a glossary at the end of your policy.

What does good <insert topic here> look like? After reading your four pages of quality text, a reader should know what the direction of travel is in respect of the topic you are writing about. If a draft policy makes a declaration of progress that can be achieved in six months, then it needs transferring to an Operations Plan, or even to a project plan – we should not be putting goals in here that are finite.

Document Management: Who owns the document? When was the document published? When is it next due for review? Who gets to receive a copy of this document? Where and how is it published? Which documents is it adjacent to/ reference? What is the scope/ reach of the policy we are writing? We are trying to educate senior management here, some of them may be curious to dig deeper into the topic – so we should be providing pointers as to where their curiosity can be satisfied!

ITAM Policy: Getting closer to the topic at hand

It wouldn’t be a blog from me if I didn’t include a reference to ISO 19770-1, and output of an ITAM Policy forms the hub of an ISO Management System.  Our ITAM Policy document should address “the why” of what we are doing with IT assets:  What business goals are we addressing? What risks are we addressing? What regulation/ legislation are we seeking to adhere to? Once we have “The what” addressed, we can round off a paragraph on that topic with “a why”.  As an example:

ITAM Policy: An Example

Technical Debt:

It is <company name’s> position to adopt an N-2 policy in respect of software titles deployed, where N is the most recent release of a software title. This permits <company name> to keep pace with security fixes to protect our client data, and further helps IT from having to retro-fit IT solutions to accommodate legacy technology, which proves expensive when software goes “End of Life”. Finally, such a policy informs Procurement of which titles are/ are not to be renewed in software contract renewals.

We’ve made a declaration as to what the policy is, and why it is in place. If a member of the leadership team wishes to challenge the contents of same, then at least they are in a position to do so without having to use ITAM specific language.

Returning to our ISO management system, the creation of our policy should kick-off the creation of an Operation Plan.  Our Operations Plan takes the headings of our policy and then goes into greater detail of “how” the policy is to be achieved.  Being a process nerd, I view everything through a process lens, which then calls out the people and the technologies needed to achieve the processes that are in place to satisfy the headings we took from the policy! Our process KPIs (Key Performance Indicators) will then demonstrate a causal link between what’s being done in the name of our ITAM Policy.

ITAM Policy: Scope

Any policy will have a boundary of relevance. Within ITAM, this could be vendor driven, or if your company is international, could be shaped by geography.  Don’t be afraid to qualify which areas of the business your policy does and doesn’t apply to.   Indeed, your policy could include a roadmap of reach based upon long-term plans to widen its area of capture.  Within ITAM, your scope should be backed up at an application-level with the creation of a Supported Software Catalogue. This is the definitive list of software required to run your organization and is a living table of data stored in your ITSM suite.

ITAM Policy: What else?

What other headings might you reasonably expect to see in your ITAM Policy? The following are offered as suggestions, and are not definitive:

  • Mission Statement
  • Vision
  • Sustainability
  • Digital Transformation
  • Legislation & Regulation
  • Compliance
  • Risk
  • ITAM & FinOps
  • Future-Proofing
  • Hardware

Can you think of any others? Please leave your suggestions as a comment to this blog

ITAM Policy: Conclusion

Hopefully, you will now have a clearer roadmap of how to tackle the creation of an ITAM Policy.

As ever, if you would like the help of SAM Charter to fast-track your ITAM Policy/ Management System creation activities, then please email me at: [email protected]. Additionally, you could do worse than download our free ITAM program accelerator:  SAM and the Bigger Picture.

Thank you for finding our corner of the web (it means the world to me!). I hope you have an awesome 2023.

Leave a comment

Your email address will not be published. Required fields are marked *