What TM1 Project Manager Should Have?

落日清风

Hi All,

Just wan't to know your thoughts about Managing TM1 Projects.
What TM1 Project Manager Should Have?
Do they require a TM1 Skills?

Please share your thoughts.

Thanks

王山振

not necessarily but its essential you have one who understands how long it takes to implement something in TM1 the right way, having a PM who dictates who long things should take to do is never helpful (in any technology)

onelovely

Yes, agree at least basic things like browse cube, understand the business that is much helpful

xiaomi1984

Depends what they're managing to be honest - if TM1's a small part of their role then technical skills are not that key but if the role's a full time TM1 PM then yes, a decent understanding of the system is invaluable otherwise the TM1 resource will run rings round him / her.  Sadly with TM1, many of the times that things take feel the wrong way round - ie, what sounds simple is often very time consuming and what sounds horrid is often quite quick.  A PM has to be able to reasonably challenge on timescales and this can only be done if a good understanding of the system exists.

Also, technical milestone verification needs to be able to take place.  Often with TM1 builds, it'll get split into sections and without the ability to verify progress, you can end up with egg on your face.  Eg, he / she should be able to understand what feeders are without having to understand the technical specific feeds that need to take place in a system.  Otherwise you can end up with TM1 resource claiming 80% of cubes are fully fed as 8 out of 10 are fed but those 8 might be tiny in comparison to the remaining two giving a false answer.  These skills can be trained reasonably easily for any IT PM though.

I would however point out that a good knowledge of the business and the requirement is probably more important in a number of cases - dropping a PM into a technical (in terms of both TM1 and the Financial requirement) project who does not have a grounding in both areas can often be a recipe for disaster.

The most key thing though is having a strong PM who will stand up to the Project Customers and Sponsors.  Nothing kills a TM1 project stone dead more than incomplete requirements, late changes, scope creep and subject matter expert unavailability, etc which is not transferred onto the plan with impact analysis.  A strong PM who will ensure that these factors are identified, measured and tracked through to conclusion is the main requirement in my opinion otherwise it'll end up with a project being delivered with the TM1 resource being unfairly blamed.

Just my 2p.

lindejink

these are excellent thoughts from Garry - and some of these comments sound all too familiar  

caoshuo594

Hi

You could try Project in your Pocket. I haven't used it in anger myself, but it has been used on real world TM1 projects. The author is currently offering it on a free download.

I think that the key difference between a TM1 project and what some would regard as a more standard IT project, is that the waterfall model is particularly unsuited to a TM1 project, since it is usually impossible to get all the requirements defined in advance. You need someone who can understand that so long as the underlying architecture of the cubes is correct, then pretty much any report can be produced, so the key activity is data and process modelling, rather than report specification.

A TM1 development works best when the TM1 developer works alongside the subject matter expert and transfers skills as they go.

Having said that I don't actually believe that the waterfall models works well for any systems development whethe OLTP or OLAP, and would always recommend an agile methodology. I think that it is just a matter of degree with TM1. A TM1 project is likely to be particularly upset by an attempt to define all requirements in advance, particularly when the user community is not used to the slice and dice capabilities of OLAP tools.

The other aspect that is common to MI projects (not necessarily just TM1) is that users will want to test by comparing reports to existing figures. It is rare to get closed loop testing where users define inputs and expected outputs. The comparison to existing figures almost invariably leads to a point at which there are differences, which can usually be traced back to errors in the current data or current reporting. This needs to be managed carefully, otherwise the reputation of TM1 can suffer, particularly as the people who managed the existing systems will have a vested interest in proving that their figures are correct.

Regards


Paul Simon

zhutou1989

Garry,
Excellent! Absolutely Right.

Paul,
Exactly, same problem i'm facing. Always comparing and making TM1 reputation suffer, this kind of things making project late, check again, add more cases, change the reports, wow lots of things.

When there is 100+ users with more than 10 applications, say it's a large organization, what is the best approach to make the user understand TM1?
cause i think with the basic understanding for elements, dimensions, browsing cubes it would be very helpful.

Thanks

sjgogo

Well I would suggest that you don't need to get all 100 users to understand it. Probably at most 20, since the 100 or so will probably just be consuming pre-canned reports, or filling in budget templates. I would say that the only way is via a demo. People don't 'get' TM1 from reading a document.

Regards


Paul Simon

玩美123

Whenever I do a project I insist on user and admin training. I can do it, they can go to an IBM class, or I can do a train the trainer and then they can train but the bottom line is if they aren't willing to train I'm not going to work with them.

fs111

The advice given in this thread is spot-on! Understanding how long a TM1 implementation can take and the traps you are likely to encounter is essential if you are to (a) manage your stakeholders' expectations and (b) gain the respect of your team. As to how you get this experience, I'd suggest the most efficient approach would be recruit a consultant (or consultancy) with extensive TM1 experience into your team for the first couple of months of your project as, with proper shadowing and handover, this will prevent a lot of heartache in the future.

You also need to brush up on agile methodologies. Waterfall often leads to an almost obsessive effort to define 'reports' up-front which rather misses the point of an OLAP system. If corporate governance dictates waterfall, there are often ways to make the process more malleable by, for instance, splitting UAT into two or three 'rounds' (with the first really being 'discovery') and by going out of your way to build relationships between your developers and the SME's so that what is delivered is not a surprise.

I have indeed just published "Project In Your Pocket" which, while a generic approach, has already been used successfully in a number of high profile TM1 projects. Details on how to get a copy can be found here.

Good luck. By all means contact me for any guidance.