-
1. HR is at the bottom of the heap. A disconnect between recruiting and marketing is quite common in corporations. While creative brainpower focuses on selling products and services, getting candidates through the door takes a backseat.
2. The IT department, like marketing, pushes the online needs of HR to the backburner. By relying on excuses like "we're just too busy right now," or "here's why that won't work," IT easily pushes aside initiatives from the department that doesn't understand technology, and doesn't know how to push back.
3. Legal says no. Just the idea of a lawyer getting involved can kill an initiative before it's even born. It's easier to just go on with business as usual instead of try something new and innovative.
-
When competency models are implemented, employees and managers usually receive some training, then the model is largely disregarded until performance appraisal time — which might not be the most consequence-free occasion for either supervisor or employee to discuss the competency model. Consider also how the introduction of a competency model is commonly perceived. For those on the receiving end of a consultant-produced competency model, the reaction often is that they are being held to something produced by someone who has never spent a single day in the role being performed (even if the model is validated with performance data for that role). Here’s where I believe serious games and simulations may be helpful. If well conceived, these serious games can give an employer the opportunity to introduce, rehearse, and refine competency models with stakeholders in an engaging, constructive, transparent, and risk-free way.
-
Architecture is an answer to a question. So many architects strive for accuracy in their “answers” (the architectural diagrams they produce), and we see countless discussions of the “correct” way to model this thing or that… but while accuracy is great, usefulness is so much more important.
In some ways, that is what the IEEE 1471 / ISO 42010 standard is all about. For those of you not familiar with IEEE 1471, it is a metamodel for all architecture. This simple document frames architecture as an attempt to communicate, using the language of architectural models.
But what is more important in the standard is not that architecture communicates… it is the fact that architecture, in order to succeed, must communicate to the specific concerns of specific stakeholders. In other words, you must consider the needs of the audience before delivering the requested information, and then deliver what they need in a clear manner, even if it is not technically what they asked for.
-
ISO standards can, at committee request, be marked stable, which means they are not expected to change. That this is not the default may be surprising to some people, especially if you have some kind tablets of stone view of standards.
In the particular cases of OOXML and ODF, I think there is a strong need to find maintenance models that are both workable, don't disenfranchise their champions, give all stakeholders an equal voice, and prevent death marches. I suspect ODF and OOXML are both very prone to the death march (i.e. where a project just drags on, swamped by feature creep and committee paralysis.