In some recent conversations, I find that it is hard to explain the notion of a capability. People want to talk in terms of software features or project requirements.
Software capabilities define value in the following ways:
- enabling the user to accomplish a “feat” in less time than they otherwise would.
- enabling the user to accomplish a “feat” at a greater scale than they otherwise would.
- enabling the user (or a group of users) to accomplish a “feat” more effectively than that they otherwise would.
- enabling the user to accomplish a “feat” that he could otherwise not accomplish at all.
- enabling the user to accomplish a “feat” better than he otherwise could.
- enabling the user to focus on “feats” that require decisions, rather than repetitive steps.
Every other benefit of software can be composed from these.
To define value, a software capability must contemplate (model) the “feat” that the user wants to accomplish.
I like the word “feat” to describe something that a user does.
- It is better than a process, because processes are merely organized, consistent, managed ways to accomplish the feat. I believe that most times, when people talk about process, or business process, they get confused and we build software capabilities that support the process, but don’t actually enable the user. Processes have steps, and we can enable steps, but if we don’t focus on the completed whole successful result, we are probably approaching the thing from the wrong perspective.
- The feat is the “money shot” of the process. Accomplishing a feat – means that we successfully produced a valuable result. It terms of capacity, we are talking about feats per unit of time – not partial feats, not attempts that produced bad results, but the successful producing of a valuable result. What I really want are billable feats, when the company gets paid for success. I will settle for required, non-billable feats.
- I have also used the words “practice”, and “activity”, to describe what my users do, but like process, neither of them really get to the heart of the issue.
- Practice is a set of principles or guidance for feat accomplishment. A practice, is the essence of the recommendations for success boiled down to a small cohesive set of rules.
- Activity may be partial, there may be multiple activities required to accomplish a single feat. Activities may also not have any relation to a feat – just stuff that people do that takes time. Now of course, I can make those activities take less time, and free up more time for feats – but in that case, I really have to turn the activity into a feat. So why am I engaged in this activity anyway. When I think of activities, I think of communication and collaboration – like e-mail and meetings. What exactly is the valuable result that I am enabling??? Much harder to say. The activity is usually not the feat, it is something we “do” on the way to accomplishment, and it is not clear whether the activity is necessary, beneficial, harmful, or simply a waste.
So lets talk about the relationships between feats, processes, practices, and activities:
- Feat – an accomplishment, a result accomplished by a person, something that we do that produces a desirable result.
- Process – a set of steps or actions defined/designed to accomplish a specific result with some high probability of success irrespective of the person performing the steps.
- Practice – a framework for making decisions related to the steps in a process, with a view to improving the probability of success of that process.
- Activity – something that people spend time on, without any specific result or outcome (e.g. reading e-mail, having meetings, or running reports)
- Thus processes are ways to help many people perform the same feat effectively.
- And practices (according to my definition) are ways to institutionalize the ideas that make one effective
What classes of feats can I envision:
- Feats of strength – require effort, patience, stamina, perseverance, more than knowledge, decision and judgment.
- Feats of skill – focus on applying specific knowledge, in repeatable decisions with judgment.
- Feats of confidence – focus on influence, convincing, persuasion building networks of trust and collaboration.
- Feats of valour – involve leadership, taking and managing risks, sponsoring and planning change or transformation.
- Feats of alchemy – apply known principles to previously unknown situations, defining new pattern, process, or practice
- Feats of magic (observing principles that were unknown, abstracting generality out of the noise of activity and broken stuff)
- Feats of unity (coordination among many, think of a symphony or a live theatre production, or synchronized swimming or a ballet)
I especially like the idea of feats of strength and feats of skill, because often, it feels like a circus around here.
The simplest feats to enable are feats of strength.
- like a war engine (think catapult) I can use technology to increase the scale (velocity, weight, distance) of the impact of my effort.
- enabling feats of strength can be thought of as allowing a single person to accomplish what many people were required to accomplish, or allowing one person to accomplish in a short time, what it used to take him much longer to accomplish.
- feats of strength rely on leverage. Leverage within a technology process means enabling a user to act en masse to accomplish many identical/similar feats in a single set of steps. Instead of carrying each box from the truck to the warehouse individually, I wrap 30 boxes together on a pallet and use a forklift to move all them at one time.
- feats of strength can be made more efficient, (more boxes) or more effective (greater probability that all the boxes will get there intact)
- feats of strength can require accuracy, precision.
Feats of skill are harder to enable.
- feats of skill require more decisions to be made than feats of strength. It’s not that feats of strength don’t require decisions – there is no work that is valuable that does not require some decisions.
- feats of skill often require much more information, because of their emphasis on decisions. Feats of skill require us to classify, qualify, quantify, project, predict.
- feats of skill rely on evaluation, problem solving, attribution – decisions more likely to benefit from increased effectiveness than increased efficiency.
- feats of skill to make them efficient, one must identify those outliers who require more diligence. Only then, can the remainder be handled en mass.
- feats of skill often are expressed as a sequence of steps with optional extra steps or paths.
- feats of skill almost always require precision, accuracy.
Feats of confidence are more driven by human interaction.
- feats of confidence are just recently being serviced by technology.
- feats of confidence rely on communication and collaboration, enhanced by asynchronous media and persistence.
- feats of confidence can rely on e-mail and “groupware” such as MS Outlook or Lotus Notes are early instances of capabilities
Here are some other ideas for software capabilities that align with these classes of feats:
- Feats of valour – project management systems, ERP systems, executive information systems, dashboards.
- Feats of alchemy – process control, business process management, workflow management, operational analytics
- Feats of magic – big data, client analytics, business intelligence
- Feats of unity – No examples come to mind… This must be the next Killer App!!!
No Comments