It is just me, or is life getting more complicated?
We all come across choices (or more correctly options) every day of our lives, in order to make decisions, prioritise a list of actions/features/requirements, or demands on our time, energy or resources (including but not limited to money). You may use structured, formal, informal or finger in the air criteria to decide which way to go. Or sometimes, like me, you might get stuck like a rabbit caught in headlights, and do nothing.
Trivial first world problem
I want to upgrade my iPhone and am confused about whether to go for the 6 plus or 6s plus. Not a biggie I hear you ask, but bear with me, more important considerations are at stake.
The decision I think boils down to features vs. memory…there are some other factors which I will come to later. Although I work in IT and am probably a geek – in the opinion of most of the world – I’m not really into consumer electronics. I like stuff as much as the next man, but I have a low tolerance for the mechanics of comparing, choosing and buying,
However, it’s time now to upgrade my creaking ancient* iPhone 4 with its sticky on/off button, dead-end operating system, and leaky charge. I’m also getting older so a bigger screen and the prospect of keeping the familiar headphone socket is attractive…hence I’m not jumping straight to the newest ‘7’.
(*Ed. about 6 years old, so several IT life-times!)
In my role as a Business Analyst I work a lot with business and [IT] system requirements. These can be functional or non-functional, for example, the difference between 3D touch and camera quality/number of pixels, respectively.
A key part of requirements analysis, whoever does it, is to help the Customer and other stakeholders to come to a decision on what is wanted, ideally based on agreed criteria. BAs or Requirements Analysts can have an opinion and some domain expertise to contribute, but normally [we] guide and facilitate the process acting as an independent agent.
Criteria to consider may include:
This means the relative costs of different features or requirements and the project as a whole. This assumes that doing everything and having it all is not an option. It never is!
Is there a fixed delivery date or some other critical dependency? This is often the deciding factor on what and how much can be achieved.
This is linked to time and money, but also the availability and skills of key individuals or groups involved. Resources doesn’t only mean people, but they are often the main driver for effecting change.
Together with Cost and Timescale these are sometimes called the Quality or Iron Triangle. These often form the basis of negotiation between various stakeholders and between the Customer and the producer, supplier or developer.
Priorities and prioritisation
This is the key area where tools and techniques can be applied to understand how important or desirable each feature or requirement is, normally relative to others. Here are some possible questions or criteria:
- Business value or benefit
- Customer/User experience
- Contractual arrangements or possible penalties of non-delivery
- Alignment with business goals
- Alignment with technical architecture
- Short-term (tactical) or strategic?
- Needs or wants; is the feature a must-have or a nice-to-have?
- Risky/difficult/complex/innovative or safe/simple/well understood?
As you can imagine it may be difficult to quantify or add an objective measure to these factors. However, help is at hand.
Putting it all together
Once you know what criteria are important you can adopt a framework or scheme to help with the decision-making process. These can be very easy to create, test and adapt to your purposes. For example use a simple numerical scale to measure each option against the criteria, ‘1’ being worst and ‘5’ being best, or ‘0’ being not desirable and ‘9’ being highly desirable.
Similarly use a more qualitative measure or weighting such as a 3-point scale High/Medium/Low or a 4-point MoSCoW (Must/Should/Could/Would), or even a 5-point Likert-style. Each measure, or multiple measures linked together, can be used to group features or provide a single ordered list.
This may only be start of the exercise, especially with many stakeholders who have different perspectives and preferences. This may be less like a scientific approach and more like a debate and discussion which leads, hopefully, to negotiation, trade-offs and an agreeable compromise! Without a process and some form of rationale, chaos and paralysis can be avoided.
A word about Agile
In an Agile or other time-boxed methodology, the time available (or development capacity) and the relative difficulty or size of your tasks may also dictate what can be achieved. There may also be a Minimum Viable Product (MVP) with all other requirements sitting below the line as optional features.
We’ve drifted away from my simple A or B buying decision.
On the face of it making decisions should be straightforward, lending itself to a systematic approach, but it seldom is. As well as all the above considerations, there are likely to be people issues to contend with, such as lack of clarity, consistency or even involvement from stakeholders and decision-makers; also politics, conflicts of interest, constraints, dependencies, assumptions, and the management of problems can make the whole thing a messy human process.
Oh and by the way, should I get an iPhone 6 plus or 6s plus…or maybe an Android 😉
(c) 2016 IT elementary school Ltd.