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…
In 2000, I designed and delivered two of the first
professional certification programs in our industry - one for Software Asset
Management and another for Technology Asset Management. Since 1988 I
have been developing and delivering collegiate-level programs in Negotiations,
Buying Technology Assets, Project Management and other related business topics.
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
AssetManagement Body Of Knowledge.
TAMBOK = What you need to know
So... Here's what I've done. I've spent the last five
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 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 Asset Management (TPM).
Understand that the copy of the TAMBOK currently
available - the Third Edition - is the culmination of a series of short, yet
comprehensive, reviews to bring together the major components of a credential
series that not only speaks to what you KNOW, but more importantly speaks 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 - to 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 added on to the responsibilities of
enterprise technicians. Instead, this is an entirely new perspective of
capabilities to be applied to 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.
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.
