The Business Technology Consumer Network
Technology Asset Management Body of Knowledge - TAMBOK Print E-mail
User Rating: / 15
Blog - Alan's Blog

I'd like to present the industry's first Technology Asset Management Body of Knowledge - the TAMBOK. You can find it by clicking on the link at the end of this post, but please take a moment to read this brief introduction.


Fair warning: I rarely talk about “me” but today, for this purpose, I’m giving you my personal/professional perspective. For those of you who may not know my background, I've been in the technology asset management industry for over twenty years. Here’s where I’m coming from…

 

Since 1988 I have been developing and delivering collegiate-level programs in Negotiations, Buying Technology Assets, Project Management and other related business topics. In 2000, I designed and delivered two of the first professional certification programs in the technology asset management industry - one for Software Asset Management and another for Technology Asset Management.  However, in 2004 I found myself forced to take a step back and to view the asset management professional development industry from a new perspective. I've spent nearly half a dozen years in intense study of credentials and of the credentialing processes used by some of the top professions - and I have been highly disappointed in the existing certification programs in our field.

 

We need a paradigm shift

Frankly, fewer than 5% of technology asset management-related training programs I’ve reviewed are performing an effective job of establishing and building our profession. Don't get me wrong: As a sort of "training wheels" beginning, we've produced some decent certifications over the past eight or so years - but we STILL haven't kicked the proprietary supplier/product habit. The vast majority of our training and certifications have been designed by, and in many cases are still delivered by, partners, pals, and allies of the very industry suppliers that created the financial and liability needs to establish technology asset management systems in the first place. (While this is not necessarily a terrible state of affairs, it CAN BE easily translated into a less-than-credible focus on "marketing" over professional preparation.)

 

I think it’s well beyond time that we converted our professional preparation into a supplier- and product-agnostic process – one genuinely designed and developed BY practitioners, FOR practitioners – a program series that is based on solid learning methodologies (Think Bloom’s Taxonomy) and shaped to help you obtain and retain professional career employment by delivering serious business value to the enterprise. This is the main reason why I worked with other asset managers to create the industry’s first non profit organization specifically focused on credentialing asset management practitioners: The Institute for Technology Asset Management. It’s also why we’ve chosen to formally document our profession in the Guide to the Technology Asset  Management Body Of Knowledge - The TAMBOK.

 

TAMBOK = What you need to know

So... Here's what I've done. I've spent the last few years working with over three hundred business professionals, academicians, and asset management practitioners to re-envision our collection of certificates into a serious credential program - one based on a cost-effective and publicly available Body of Knowledge as well as a credible credential preparation program of study. Together, we have built this Guide to the Technology Asset Management Body of Knowledge (TAMBOK) to accurately reflect the skills you need to perform well in the fields of Software & Copyright Compliance Assurance (SCCA), Software Asset Management (SAM), Technology Asset Management (TAM / ITAM), and Technology Portfolio Management (TPM).

 

Understand that the copy of the TAMBOK currently available - our Third Edition - is the culmination of a series of short, yet comprehensive, reviews to bring together the major components into a credential series that not only speaks to what you KNOW, but also to what you can DO with that knowledge. The major components of the TAMBOK include the following:

 

Four Life Cycle Process Groups

  o Procurement

  o Distribution

  o Operations

  o Governance

 

Six Practice Areas

  o Portfolio Management

  o Business Management

  o Financial Management

  o Risk Management

  o Contract Management

  o Project Management

 

And Over Fourteen Applied Competency Areas

  o Think about focused applied capabilities in topics such as Negotiations, Audit Methodologies, License Management, Documentation Management, and others.

 

We've come a long way with these professions since I first developed and implemented the knowledge infrastructure of my former association. After extensive research and development, our working group determined that we need to take the next step of converting the traditional certificate process from a few hours of lecture followed by a memorization test - into a credible credentialing system that mirrors the success of such credentialing programs as those provided by the Project Management Institute, the AICPA, the Contract Managers Association, and others. (There is an extensive list of organizations from which we drew samples, guidelines, and advice in the TAMBOK Appendix.)

 

That next step begins with a formal Body of Knowledge - the TAMBOK - on which we can build and evolve a solid foundation of applied capabilities. The TAMBOK is not a derivative work that attempts to bend technology skills into a new service by simply grafting it on to the existing responsibilities of enterprise technicians. Instead, this is an entirely new perspective of capabilities to be applied to managing the Business side of the Technology Portfolio.

 

And, to further clarify the potential of the TAMBOK, we’ll soon be presenting a highly unique Knowledge Briefing Series covering how "What you know," is converted into "What you can actually apply," which translates into "The value you can deliver with a significantly more credible credential."


We'll be the first to admit that the TAMBOK isn't perfect - it's a work in progress. But this document IS the first supplier- and product-neutral effort by a credentialing body in our industry to bring order from chaos and to place your cost-effective Professional Development Blueprint in your hands where it belongs.

 

The TAMBOK is available HERE

 

Comments are welcome - as are qualified practitioner volunteers to help evolve the next release.

 
Reduce the Costs & Risks of Buying Business Software Print E-mail
User Rating: / 9
Software Asset Mgt. - SAM Strategies / Tactics

This article is in response to, and supplemental to, the article on ZDNetAsia: "4 tips for buying 'big' software," by Patrick Gray - as posted in TechRepublic on 5 May, 2010.

I've observed well over a hundred negotiations where enterprises spent tens of millions of dollars for highly complex software (and/or hardware). In parallel actions I've seen thousands of small to medium-sized companies spend enormous percentages of hard-won revenue for products they didn't need, couldn't effectively use, and shouldn't have touched. In virtually every case, the enterprise or company making the purchasing has been hammered by supplier negotiating teams.

Here's a few issues to consider BEFORE dropping all your spare bucks on big money technology goods and/or services. Also, keep in mind, if you genuinely want to reduce the costs and risks of business technologies, you can take a wide range of simple, cost-effective actions. BUT, you have to commit to actually DOING asset management - merely talking about the game will not help you gain value.

Nobody is permitted to speak with ANY supplier about the project - PERIOD!
  • Why do I bring this up? Because, time after time, I've seen people come back from conferences or conventions where they have "found the perfect product to solve all our problems."

  • Major violators of this rule? Technical people and management. Rein them in BEFORE they damage your options.

  • Result? The supplier already knows precisely what your project looks like; its schedule; its budget; who will be on the internal team; and who will be part of the decision tree.

  • Since the supplier has also conveniently learned the details of ALL your requirements, their product or service is going to somehow magically fit exactly inside your needs analysis.

  • When - not if - this happens, you can kiss negotiations goodbye - because you will have no leverage with this supplier.

Conduct, and follow, accurate analysis - EVERY time.
  • If your company is typical, you purchase new technology goods and services for nearly ALL the wrong reasons. (Don't get all defensive on me until you read on.)

  • Conduct clearly defined, honest, and complete analysis. Make sure that they are accurate and not filled with vendor hype - as well as supporting "pet" projects.

  • Pick one or more: Needs Analysis, Cost-Benefit Analysis, Feasibility Study, Forcefield Analysis, Business Case Analysis, Cause & Effect Analysis, Stakeholder Analysis - ANY of these will take you further than you are already going in terms of whether or not the acquisition or project is genuinely necessary. (Incidentally, The Institute for Technology Asset Management - www.TAMinstitute.org - is the only professional organization of its kind that actually teaches you how to conduct over 16 of these critical business analysis.)

  • The key is this: Fewer than 10% of enterprises actually conduct any serious level of structured analysis prior to beginning the acquisition process. Of that number, fewer than half ever follow up to ensure that the goods or services acquired actually ADHERE to the expectations. Even more critical is the tendency, in nearly ALL analysis, to insert personal perspectives in place of quantifiable documentation. Result? Decision makers are coming to conclusions that are NOT based in fact or actual business needs.

Negotiate based on what you expect to happen, not based on supplier representative assurances.
  • If you do nothing that I recommend, at LEAST do this. Every agreement that I have read in the past 23 years has a clause somewhere that clearly states that ANY statement or assurance given to you is null and void - the agreement supercedes ALL verbal discussions. (You don't have to believe a word I say. Just get up out of that chair and go read a software license - any license to confirm my rantings.)

  • So? If you want any specific issues made clear in the agreement you will have to negotiate them in. (Trust me, suppliers do NOT appreciate it when I give this advice. It means that they have to actually deliver the value they claim.)

  • This interestingly hidden little caveat also seems to forget to mention that the functionality of the product, as delivered, does NOT have to match what you were told it would do. Again, if you expect to get the value for what you purchased, you better negotiate your specific expectations into the agreement.

The actual costs of this acquisition are NEVER what you think.
  • You should already know this but nearly ALL of us tend to forget. We get excited about the new toys and slip off into Christmas morning... What to do?

  • Patrick covers this but I'll expand - When you conduct the Cost-Benefit Analysis, step the process out at least three to five years. Check with anyone and everyone who has touched this product. Find out what worked out well and...well...what didn't work out. Document it ALL as part of the CBA - BEFORE you spend a single penny!

  • Check out implementation costs and be sure to match them with the specific talent brought to bear on the project. If you think your internal team is going to implement better than a highly trained and experienced (think: expensive) support team, you may be in for quite a financial surprise. But, if you planned and budgeted for the difference in team talent, you may find financial relief.

  • What about defects and patch management? Upgrades? Ongoing support? Check into the actual details of each and every one of these items. Look over the actual supplier contracts for the "rough" spots. Does support cost more if your own team implements the project? Is this product so full of defects that the supplier has a monthly patch day scheduled for every consumer of every product? Are there cute little items such as the "product cannot be used more than 15 miles from the server" or implementation support is billed out as "$180 per call"? (If you don't know about these interesting little revenue stream inserts, you really should spend some quality time in one of my technology asset management courses.)

Beware the Reference Fruit Punch Shuffle!
  • Patrick mentions being alert to what I would call "happy people" references. You know the ones I mean: "I invented Windows 7." Keep in mind that a supplier would NEVER connect you with someone who had a nightmare failed implementation. If you rely on supplier connections, you'll only hear from the folks who consumed the entire cup of fruit punch.

  • As an element of this particular common scam is the supplier advertising budget. If the product is so great, why do you have to spend so many tens of millions of dollars TELLING me about it? If implementation and ongoing support are so simple, why do I constantly hear, or read, about over budget, over time, and failed projects?

  • You want references? Check with the people who have lost tens of millions on failed projects with this product line or supplier. THOSE folks will give you a totally different story than the ones who had plenty to spend and plenty of talented techies to contribute to implementation and ongoing support.

Manage the Project
  • Patrick's observations regarding the implementation partners is right on track. Keep in mind that any enterprise that has reached the "Partner" stage of a relationship with a major software publisher has also consumed massive quantities of that ever present fruit punch. These folks make their livings via their relationship with the given software publisher. If you honestly expect them to admit the product is a dog - don't hold your breath. Instead, they'll follow the supplier pattern of letting you pay to resolve the problem so the supplier can wrap it into the next release - the one you'll pay to acquire.

  • For a major software acquisition & implementation either use your own project manager or follow Patrick's advice and bring in an independent PM to monitor the project - even a spot check will be better than nothing. But, let's take this a little further...

  • IT projects fail significantly more frequently than they succeed. There are plenty of reasons for this - some of them are even reason-able. But, as a PMP and a faculty member teaching project management I have found that the key to project success - or failure - all-too-often rests on the heads of project sponsors, executive management, and the initial planning team. THESE folks need to be visibly and aggressively on board or the project manager might just as well be a NATO observer.

  • Remember that "negotiation" thing we discussed? It also comes into play right here. Place serious penalties in the acquisition agreement to "encourage" the implementation company to get it done right. Wrist slapping does not belong in this clause. If it is going to cost you $1M for the product, $2.5M for the implementation, and $5M to correct failure - include those costs in the failure clause. Otherwise (as clearly stated in the software license) the software publisher needs only refund the price of the software after it fails and they blithely walk away from your completely devastated IT environment.

Is there more? Oh, absolutely! In fact, there are literally hundreds of "gotchas" hidden inside every software acquisition - whether it's a simple operating system or a major overhaul. If you expect to gain value from business technologies, you absolutely must learn to identify, define, and pursue that value. Otherwise, the suppliers are in control of your money and (lack of?) results.

Thoughts? Comments? Observations?

 
<< Start < Prev 1 2 3 4 5 6 7 8 9 10 Next > End >>

Results 1 - 5 of 67


Sphere: Related Content

Recommendations

What's Plastow Reading?

Review of Books & Articles:

Learn more to earn more!


Review List...

Member Status Center

We have 14 guests and 2 members online
  • uabeuwilb
  • dwegrzynclif

Syndicate