Hi,
Just to keep you entertained until lotsaram shows up, here are my thoughts:
I assume your questions relate to internal developers within an organisation (external consultancy firms would have differences)
How do you take on TM1 projects initially?
One of 2 ways:
Boss informs you of a new requirement.
Developer team actively seek out opportunities within organisation, as part of efficiency drives etc. Increasing data maturity and all that spiel.
What steps are taken to assess if TM1 is the right fit?
Assess requirements - from security, calculations, to how users will interact with the solution. How long development is estimated to take.
Understand source data
Understand data flows
I should note that in some TM1 models I have developed, the solutions sometimes come from outside TM1. For example, I had to report and plan agency staff, and in order to facilitate this, procurement and payroll had to change their procedures to give the agency an employee number and include certain data on the invoice order.
Another example, an organisation changed its entire vacancy rules to facilitate a TM1 project, so vacancies older than n number of months got auto deleted.
Do you set a limit on complexity by the number of lines in rules? For example, does a single model with 20+ cubes and over 15,000 combined lines of rules raise red flags?
For me it is more a question of userability vs performance. TI's vs Rules etc.
I notice in a few of your posts that you don't mention TI's much but you do mention rules, I personally like to see a mix. But depends on the model.
One bit of advice I would have is to always include a Manual Adjustment measure where appropriate, so the end users can adjust the figures by simply entering a value.
This gives the end users some level of control and avoids you having to continually tinker with the logic to cater for immaterial and trivial requests. It can also tick off a few problematical but trivial areas during development!
Also, ensure the model is future proof and includes appropriate error trapping. For example, if a data load fails it should be easy just to reload, rather than say having to restore a back up.
At what point do you say HOLD UP let's use another tool?
At the point there is a complete show stopper! Otherwise you muddle on.
I remember starting work on a schools insurance fund model. At the same time the web team were developing a new front end for schools to submit insurance details.
The way the web form was designed meant a veritable forest of trees/paths, which resulted in the TM1 source file having 400+ columns.
At that stage I was wishing TM1 had not been the go to solution!
Do you have a set of guidelines that dictate the appropriate tool for the job or just go with your gut?
Generally it is a gut feeling, though one based on past experience and knowledge of the tool.
I usually reject TM1 as a solution if the requirement is really simple, as I often think why are they suggesting using a sledgehammer to crack a walnut.
Generally if it is really complex, and it makes material efficiencies I am more inclined to suggest TM1.
Lastly, I fully agree that managing user expectations is the key, and emphasising materiality. Getting excel loving users on board is the biggest challenge in my experience.
regards,
Mark
