There is something missing from the table of IT elements!
No I don’t mean the latest whizzy gadget or device, Internet of things, Virtual Reality headsets, drones, Smart TVs, Apple or Samsung phones…these technologies will come and go, and have no place in this collection of core concepts, tools and disciplines.
What’s missing is more fundamental; the raw elements that underpin why organizations exist and do what they do; the rubric of all businesses, be they commercial or not-for-profit, traditional or digital. These elements can also be extended to other non-trivial projects and planned endeavours.
Here are some questions that an imaginary business owner or entrepreneur might ask, but would struggle to find the answers in the regular table of IT elements:
– Why does my business do what it does?
– How does the business function, both strategically and the day-to-day operations?
– How do I know if my business is successful or not?
– How do I stop it all going wrong!
– How can computers and technology help to automate and enable my business aim and objectives?
The answers are in six new elements, which I am calling the Golden Group. Each is important in its own right but they are also closely bonded together.
In this article I will explain what each topic means, and in Part 2 I will illustrate the way that these elements link together using Business Modelling and Entity Relationship Modelling techniques.
Why it all exists
All man-made constructs exist for a purpose, to achieve some explicit or implicit (tacit) aim and objectives and that includes organisations, strategies and individual change programmes and projects…as well as community groups, charities, even nations and religions!
Aside from the simple need for most organizations to make money to acquire resources (including people) and then generate a profit…or not make a loss…the underlying rationales are much more interesting. For example, the aim could be helping or educating people, serving some social purpose, the desire to be the best at providing service A or building product B, or achieving a particular target or mission, such as a sporting or fundraising challenge.
Without some rationale and a commonly-accepted Business Narrative, it’s harder for employees and supporters to be motivated, investors to invest, customers to buy or users to use. Why make it hard for any of these groups to fully engage with you?
Thinking about why is a good habit to get into; it can help with cascading strategic plans, operational targets and sought-after behaviours. It also provides a mechanism for lower-level justification of activities, and the prioritization of spending decisions & resource utilization.
Here is a simple example of a User Story about your favourite source of information and guidance on IT and related subjects 🙂
Stopping it going wrong
A rationale for an organization or project might be to respond to an issue or problem or take some defensive action against unwanted or potentially costly events.
External risks can be both challenges and opportunities, for example the growth of cybercrime has spawned an industry of information security specialists, alongside more traditional physical security measures.
However, the main reason that Risk is in the Golden Group of elements is the need to understand and manage risks within an organisation or project, sometimes embedded as a Project Management responsibility or a separate Compliance & Risk function. Risk Management as an overall discipline will be covered elsewhere in the IT elementary school, but in summary the approach should contain these key stages:
Risk identification – identifying possible risks to safety and security, financial or reputational loss, competition, degradation of service or performance etc.
Risk assessment – answers the questions; ‘how likely is it that the risk will occur?’ and, ‘…if so what will the impact be?’
Risk control – putting in place measures to prevent or otherwise reduce the likelihood of the risk event or situation occurring, and lessening the impact if it does happen. These measures are broadly referred to as mitigation.
Risk review – repeat cycle based on the changing situation, both internal and external factors, and a constant vigilance for expected and unexpected events or changes.
Keeping it all on track
As alluded to earlier, all organizations that are man-made or imagined realities need rules to be adopted and sustained. These rules dictate how things happen, or should happen, in a number of areas:
– Internal functions and policies such as recruitment and terms of engagement, staff performance measures and rewards, discipline, health and safety etc.
– A special set of internal rules called governance determine how and by-whom the organization is governed. Governance establishes power and duties, (responsibilities, accountabilities and decision-making), ensures viability and prosperity (how funding is allocated and spent), and monitoring (reporting, escalation of issues), and other process and quality mechanisms. Governance practices are also likely to apply to transient project work as well more stable organizational constructs.
– Policies, rules or guidelines are also set by external bodies; including government, tax authorities, specific industry bodies, provision of goods and services acts, data protection legislation etc.
– Business Rules, whether formal or informal these allow organizations to trade and make day-to-day operational decisions. They might cover areas such as pricing, eligibility, data coding, mapping and translation, calculations and formulae, as well as the specification of configurable features. The latter covers subjects as diverse as inventories and product configurations to the personalization of services offered to Customers.
All these rules can happily operate without computers or automation. However, in the information age they could also be embedded in IT systems and should(!) help to ensure compliance, contribute to operational efficiencies (normally meaning cheaper, quicker and more competitive), and reduce errors.
Making it all happen
I have mentioned organizations of different types, brought into being to achieve some rationale and underpinned by rules. Add processes, people and usually some technology – of which more later – and we have a system, or business system in this case. There is a rich body of research, theory and applied techniques about systems and how they work, which I will not go into here.
For the purposes of this article, systems provide the means by which objectives are met, business rules are complied with, risks are managed, and performance is monitored (next section).
As technology is such an integral part of most modern organisations it is difficult to separate the business need from the Information Systems that enable and support its objectives. That includes the technology needed to carry out the business (operations), create and distribute products & services to consumers, as well as the internal infrastructure such as telephony, desktop applications, internet, security etc. I will use the generic term system to cover both.
Man-made* systems are not – or should not be – static entities limited to perpetuating the status quo; they must respond to internal and external change, and make use of feedback mechanisms and regular review and recalibration exercises to ensure conformance, relevance and effectiveness.
(*Ed. systems also exist in the natural world that will follow a different set of rules, erm, not man-made)
Knowing how it’s all going
Systems and processes can be up-and-running and people can go about their work all more or less efficiently & effectively with little formal governance. Conceivably a one-man-band and smaller orgranisations can get by on such an informal basis. Charles Handy, in his book The Gods of Management identifies a Zeus culture that has a central influential figure managing, and controlling activity, making key decisions, delegating or allocating resources and casting the organisation in his/her own image.
However, the more complex the endeavour and the more people involved, there is a greater need for independent management, administration and bureaucratic functions to provide, for example, progress updates, formal reporting, measurement of sales & expenses, tracking activity (who, what, when, at what cost). I have grouped all these operational metrics under the umbrella title of performance. This information is required for a number of purposes and interested groups, including:
– Management with budget responsibilities or specific accountabilities, from operational and functional line managers to Director-level seniors.
– Stakeholders interested in activity against plans and progress towards targets, possibly aggregated and analyzed into a management report.
– A special subset of stakeholders with a financial stake or oversight including investors, shareholders, owners and trustees.
– Requirements for external statutory & regulatory reporting.
Returning to the Gods of Management, there are many different models to organise people and implement command and control structures, but in all cases measures of performance are important.
Making it better
Finally, possibly the most surprising element in the group, but a key mechanism for measuring performance, monitoring risks, and ensuring that systems work effectively.
Here are some examples of feedback in practice:
– Comparing progress actuals against plan estimates, i.e. to determine if we are at the point we expected to be at this time, and have expended the expected amount of resources/money?
– Reviewing the quality of a product, stage document or artefact against the specification (verification) and the requirements (validation). All testing has an element of feedback.
– Customer surveys, research questionnaires, system quality audits, [Project] Post Implementation Reviews (PIR), assessment of performance against a benchmark or standard including monitoring and formal inspections, or in the case of people, examinations, This list goes on.
– Accessing the quality of a process, business function or marketing campaign. And in the agile world, show-and-tells and retrospectives are used to answer the questions, respectively, ‘Have we done what we said we would do?’ and, ‘Could we do it better?’
This last example illustrates neatly the difference between backward-looking negative feedback and forward-looking positive feedback, both of which are needed in any mature system and processes.
This has been a longer blog post than normal, but I hope you have read this far and have learnt something useful about the Golden Group of elements. Part 2 takes a more creative right brain look at how businesses can be understood and modelled, and how links between these elements can be represented.
© 2016 The IT elementary school