Affino and the Art of Phasing

When implementing an Affino Digital Business Solution, you need to have clear goals in mind before you settle on the final configuration. No matter what you select, there will always be follow-on phases to the project, as everything can of course be improved upon and refined.

The huge scope and scale of Affino is such that it would take a very significant time if you wanted to make use of every single element of functionality on offer. That said, when most Clients get into Affino, they almost always want to add more elements which are outside the original scope and proposal.

There is often not sufficient consideration as to the impact of front-loading more features and functions, as this almost without exception will impact on timelines and costings. And it is rarely a case of sacrificing a little bit of something agreed for something slightly different. All additions have knock-on effects in one way or another, and some of the seemingly smallest ones can be the most significant.

There are of course some business-model reasons why it may make perfectly good sense to make alterations to scope. But a lot of the time it is more of a case of simply having more bells and whistles at launch. Throughout the process you must consider the most typical end-user / consumer, and gauge how receptive they will be of the overall solution. Too much too soon is not always a good thing. It goes without saying that the core functionality should be in place. But it is usually a much more successful policy to phase in new features and functionality on a more extended timescale - and within some sort of environment of co-operaiton and consultation.

I have evolved some helpful rationale for assisting in some of the key decisions:

Dates vs Contingency

Probably a greater number of projects have seemingly unmovable target dates which don’t adequately make room for contingencies - which become more important, the bigger and more complex the project becomes. When you are doing something new - which most digital business deployments tend to be - you are rarely just copying exactly the same template and running with all the same settings and tolerances. In most instances inadequate planning consideration is given to full testing and soft-launching. If the date is totally hard and fast, then there has to be some flexibility in the scope - in terms of the usual PQT triangle dynamics. As almost without exception new evidence arises during implementation and testing which results in some degree of change of plan - which in turn means more time will need to be spent in certain areas. With complex systems there is often a further knock-on effect which means redevelopment / optimisation of other essential components is required. So as every single development manual warns and advises you will usually have to make some concession to what is developed and for when.

Essentials vs Nice to Have

When you launch your new solution the essentials have to be in place to make the business work, often you also need specific differentials to set you apart from your competition. And these together are everything that needs to be ready for launch. There are then a load of Nice-to-haves - which add a little extra value and quality, but are quite obviously not needed for the business to work successfully. People often get hung up on all the Nice-to-Haves which delays the launch of the business - where you could have been making money / more money already.

Soft Launch vs Big Bang

It is almost always in your best interests to engage in a soft launch - i.e. trial the site with a smallish but representative group of customers for a few weeks - before you launch to everyone. No matter how much testing you do, there will be some issues that only materialise when real customers are using the site. Those that do hard launches often experience unnecessary stress in dealing with high-pressure issues - which would have been far more manageable in a more controlled soft-launch operation.

Rapid Release vs Consultation / Suggestion Box

Experience tells us it is best to work in consultation with the end-users. Give them a voice in the development of the service and they are more likely to become loyal advocates. There are good and bad ways to go about this - do not have a negative stance in terms of getting people to report what’s wrong. Instead have a feature request area / form or some sort of suggestion box for users / consumers to recommend useful updates. You can even offer some sort of relevant reward - extended membership etc. for good ideas. This can also be used strategically to find support and endorsees for new innovations and forthcoming changes to the service. As always we encourage Affino site owners to be aware of vocal minorities and silent majorities when dealing with certain issues - you always need a critical mass of consensus to get a proper gauge of where your customers mindset is at. We also advocate structured 6 month / 12 month updates as too much chopping and changing can be discouraging and disorienting for consumers.

Bedding-In vs Knee-Jerk

Everything takes a while to settle in or settle down. Whether a new car or new musical instrument, they need to be broken in to a degree before you can take a proper status on how smoothly they are operating, The same is the case with digital business solutions. We’re not meaning bugs and glitches here - as for sure those will need to be ironed out as soon as possible. What matters here is the processes and workflows - whether these are working optimally, whether everything is easily learnable and suitably user-friendly. When you present anything new, you always get a load of kickback from certain types of individuals. We encourage you by all means to take note of the feedback, but bide your time and take a circumspect view on proceedings. You will rarely please all of your customers all of the time, so it is important that the vast majority are suitably satisfied. There will always be complainers and disruptors, and you will need processes for dealing with them. You most be responsive in communications, set out your direction clearly, but not necessarily act on something which may be a vocal minority view.

Short Term vs Long Term

An original Affino site implementation takes anything from a few weeks up to around 18 months for the more complicated builds - usually conditional on how much of the required functionality is entirely new. The short term timespan depends also as much on the degree of complexity of build and size of solution - so mileage can vary significantly. We do encourage more longer-term strategic thinking with clear milestones at annual or six-monthly intervals. It makes sense for some to be on a quarterly basis, but doing monthly updates is probably too much, as every new introduction takes a while to bed in, and will have some unforeseen knock-on effects which may take some time to smooth out. Like with Apple, customers like to know there are regular updates and innovations, but too many of these and it becomes a negative, a disruption and an inconvenience.

Launch vs Phase 2

This is probably the biggest area for headaches for both us and our Clients - and always involves additional features and functions identified during the process of implementation. The fact is that there will always be a phase two, various aspects of an implementation can always be improved during a review and various behaviours come up only when the site has been fully in Live mode for a while. There is the question of opportunity cost in launching the site later versus the opportunity cost of launching something perceived incomplete or nonoptimal. Change requests themselves can be quite messy, and a seemingly small adjustment may mean quite significant additional development work. So it’s back to reviewing the PQT triangle in terms of discerning where you should draw the line in the sand. There has never been a 100% perfect launch, in much the same way that pretty much every printed work out there, no matter how often reviewed normally has at least a handful of mistakes - typographical, spelling or grammatical. The more user data you have, the better you are able to make your solution - which means usually the solution being active in the real world and dealing with wholly real-world scenarios. Some of your perceptions may be proved wrong, so it is often in your best interests to keep a certain amount of tasks in reserve for phase 2 - depending on feedback and outcome of the actual launch...