Introduction
...
- what skills do they have (physical competency - bricklaying, plumbing, electrical work, roofing, carpentry etc)
- what are their competencies (education, qualifications and areas of knowledge - bricklaying, plumbing, electrical work, roofing, carpentry etc)
- what will they charge and what is the payment model
- what's their work ethic (turns up on time, is diligent and doesn't leave a job half done, honesty)
- how quickly they get the job done - can they deliver in the time allotted
- customer relationship management (how much they keep me informed about the costs and what they are doing) - communications skills
- have they go the tools for the job (good knowledge of the right tools for the job) - equipment
- what is the quality of their work (consider TQM as defined by Toyota)
- how well organised are they, this will involve the team around them and how effectively they work as a team
- how well they understand your requirements
- how well they understand building regulations
In this example you are measuring how capable the builder is using a number of criteria as listed above, and not based upon just the service they offer. So a capability is more than a service or a function!
Use the following statement as a guide to this thinking yourthinking "being able to do building work doesn't make you a competent builder". Most people can run (to some degree), this doesn't make them competent runners, that competency comes from training, eating well and plenty of sleep. In other words there are a number of key characteristics that must be developed in order to enable that capability (see comment 1 below).
The next thing to remember about a capability is that it is more than just a business function, service or team. It is a logical entity with distinct measurable characteristics ( described aboveas shown above in the building example) that work together to achieve a desired outcome. Typically a capability considers the following (a MOD perspective on the characteristics of a capability TEPIDOIL)
...
Alternatively one could choose to define capability using the architectural unification approach POLDAT
- Process (business processes)
- Organisation (structures)
- Location (Geographical information)
- Data (models, life cycles, security etc)
- Application (software, security, interoperability etc)
- Technology (infrastructure)
Both TEPIDOIL and POLDAT pay no attention to organisation unit boundaries (business unit, sector, service, function etc) but weave a path through organisation unitssegments of the enterprise, selecting those areas within those units segments that, deliver the characteristics needed by the capabilities.
...