Ultima recommends both to
- Its partners,
- And its customers
to follow this scheme, while implementing a typical project. It consists of the following major stages:
0. Acquaintance
It all begins when you leave a request on our website (or make a phone call). Anyhow, you’re telling us something like ‘wow, we got interested, let’s meet and you’ll tell us everything.’
The meeting goes in a you-talk-we-listen format. You: tell us about your business, your problems – why you approached us, what’s wrong with the current situation, what you want to achieve. The more specific you are – the better. We: listen, ask clarifying/leading questions, and we DON’T tell (and DON’T show) you anything.
Our main objective at this stage is to get an overview of:
- main business processes of the company – what kind of business it is and how it operates;
- whether customer goals are rational and achievable (if we’re so fortunate that the customer can clearly state them)
- whether customer decision makers are competent, and, in general, whether the suggested project management scheme is viable, considering tension and personal issues (if there are any) between project stakeholders on the part of the customer.
So, in a nutshell – we’re there to detect obvious freaks with cuckoo megalomania and/or spider jars of intrigues, thus filtering out plans that are doomed to fail.
As they say, ‘tis better to lose with a wise man than to win with a fool’. More details on that in the respective essay ‘What kind of clients we don’t want.’
As a result of the first meeting, we get mass data to chew over for the following few days. After that’s done, we go on to the next stage.
P.S. A separate article is devoted to a subcategory of people taking interest in our services, who in their first message suggest that ‘we come and make a presentation of our software.’
1. Preanalysis
If both
— Us
— And the potential customer
have positive impressions after stage 0 – ‘Acquaintance’, then work on (still a potential) project goes to the next stage: ‘Preanalysis’.
While at the acquaintance stage we generally tried to figure out, what kind of business you have and how it operates now, at the preanalysis stage we try to agree on a mutual vision of what the result
should look like.
I.e. – how your business will look like and operate after a successful installation of Ultima (a so called ‘to be model’).
Here we attach a deja moo image that still has not lost its edge over the years.
Continuing the comparison with the factory from the text on presentations, – at this point we learn
a) that what you need is indeed a factory
b) what it will manufacture
c) its production volume
d) external conditions for construction
e) external conditions for raw materials supply and sales of future factory products.
And a million of other less important factors (let’s keep it simple).
Continuing with the comparison continuum – what do you want to see as an output? A stroller? An egg boiler? A submarine?
No problem.
Problems start, when you want to have a shoehorn with nuclear ICBM.
What we do at this stage (from here on we’re talking about a to be state):
- agree on how main processes of the company being automated are going to work. By main we mean the ones that add value (and them only).
- make decisions on main roles (equivalent of job positions in the traditional bureaucratic organization chart logic) and their functions – ‘who does what’. The main roles are the participants of the main business processes.
What we don’t do at this stage: all the rest.
We don’t go deep into detail; we don’t discuss technical issues and future secondary business processes.
All of that is very important, but it’s not the main thing. Details are clarified at the next stage – ‘Technical requirements’.
It’s not like the preanalysis is the most important stage (what’s more important for a house – the walls or the roof?), but it’s definitely the most intellectually loaded one, if duly processed.
We won’t commit a major sin against scientific accuracy, if we equate this stage with business processes reengineering.
We must say that very often in the course of discussions we come to conclusions, unexpected by the potential customer. Unexpected, however, only at first sight.
If at this stage Ultima Consulting comes into play (on our part, we recommend that the Ultima partners do that for all non-typical projects), such surprises are more of a rule.
If, as a result of the reengineering, there are no significant discrepancies between how we perceive the to be state and how the potential customers does – then great, we move on.
In case there are significant discrepancies, then alternatives are possible:
- if the potential customer speaks such nonsense that under no circumstances it’s going to be viable (as a rule, this disease progresses against a background of a lordly high-handedness, intergalactic megalomania and way too much inadequacy), then our relations end. Continuing with the doctor-patient analogy, if a patient disagrees with a diagnosis, what kind of effective treatment are we talking about? Consult another specialist.
- if the potential customer insists on including into the to be model some garbage, that however, has no influence on the project as a whole (this definition includes both completely harmless (as much as useless) gimmicks, that are so dear to the owner, and obviously harmful, but small-scale adjustments), then (as a rule) we do what the customer wants. However, we record our ‘minority opinion’ on each piece of such garbage, as well as an outcome prediction, in the form of a disclaimer within the Technical requirements (see the next stage). The patient is asking the doctor to ‘please, please add to the prescription that spirituous tincture, that’s nothing for you. My wife forbids me, but now that this is for my health and is prescribed by a doctor, she wouldn’t mind!’ ‘OK, dear patient, I’ll add three vials here, you just don’t overuse it too much!’
All our activities within the preanalysis stage are completely free of charge.
Its duration, depending on the case, ranges from a week to a month.
A typical list of activities, apart from meeting with decision makers on the part of the potential customer, includes a series of interviews with heads of the main (in the sense, defined above) functional organization units, observation of their work (‘a Gemba walk’), and, in some cases, interviews with linear staff – candidates for main roles in the to be model.
2. Technical requirements preparation and approval
After we come to a mutual vision of what we want to have in the end, it all becomes simply technical, starting with developing and approving of the Technical requirements (TR).
The TR is a document, which clearly and exhaustingly describes operations of the company in the to be state (in the Ultima understanding).
In other words, the TR describes WHAT the system has to do – rather than HOW it is designed or HOW it is going to do that.
The TR is an analogue of a workpiece drawing, rather than a description of miller machine operator actions to manufacture it.
An exemplary TR is invariant to the system being implemented.
The TR contains:
- a rigorous description of all business processes implemented: both main (discussed at the preanalysis stage) and secondary (a back office, roughly said);
- a list of business objects and their properties;
- a list of reports and their properties;
- user roles and rights.
The TR does NOT contain the favorite motive to flap mouths for many many hours (this refers to a certain character type, frequent among customer representatives): descriptions of screen forms, location of checkboxes and buttons.
This phenomenon is primarily characteristic of (but not be limited to) companies that are run high-handedly (=poorly); discussing buttons for their employees is a rare chance to feel (at least some) importance and power. Sorry, guys, but we won’t play along for you with that.
We’ll say it again: the workplace ergonomics is very important, but it is discussed (and corrected on the fly) during the training process of those users, who are going to use it.
In some cases, when it is really necessary and the functionality is particularly complicated and sensitive, we draw up a Technical specification (TS), which will be an appendix to the TR.
Why do use the capital T in the word ‘Technical’?
Because it’s the most important document.
It defines the project scope – what needs to be done – which, consequently, defines both the timeframe and the money.
Once again in other words: the Technical requirements content defines hundred percent of the future functionality of the system. If something is not mentioned there, it won’t be done, regardless of it even being self-obvious to the customer.
More precisely, it might be done, but with a separate budget and in time outside the limit.
Caveat emptor, as Ancient Romans used to say. They had an eye for both commerce and management of most complicated projects.
So read it carefully and more than once, discuss, argue, make corrections. As opposed to the frequent approach: ‘come on, guys, it’s OK, let’s just do it, we’ll figure it out later in case anything goes wrong’.
It’s better to think an extra week and save a lot more ‘later’. Including the nerve cells that are so hard to restore.
A TR usually costs around 10 to 15 thousand euro; half of that sum is paid BEFORE, and the other half – after it’s approved by the Customer. The cost of the TR is included in the total project cost, which you can see in the configurator.
The time for producing a TR usually ranges from two weeks to two months.
3. Issuing a quotation
After the TR has been approved, we calculate money and time, and issue the quotation. It contains the number of Ultimate licenses and components, the work scope divided by stages (if there are any), the cost and timeframe for every stage, the proposed payment schedule, the hardware system specification (purchased by the customer separately).
Satisfied?
Let’s do it.
We sign all contracts, you make the down payment (as a rule, it’s 30% of the implementation costs – and NOT of the whole project).
4. Project work proper
For several months programmers and analytics do their work, users go through training, websites are designed, hardware is delivered and set up, Oracle and Ultima are deployed, automatic data transfer from the old system is set up.
Other general efforts are also made.
All of this is time-consuming, often troubling, but, in essence, trivial.
5. Commissioning
It’s as bad as a fire, two floods and three earthquakes combined. Their magnitude and destructive power depend on the quality of the TR, as well as on the pre-operational testing period and user training quality.
One way or another, within a month the everyday work (with the new system) resumes its natural course.
In cases of well managed projects where we see constructive interaction with pro-active and responsible customer representatives, the flood is reduced to a storm in a teacup, while the natural course of events is resumed within a week.
6. Final settlement
Work is done, now it’s time for the payment.