![[PM4K] - The Book @ AMAZON](http://3.bp.blogspot.com/-uWOvpXmAZEA/VZs0HpFXCyI/AAAAAAAABFE/EC07hE7dUTw/s1600/PM4K%2BBook%2BCover%2Bv3%2BJPG.jpg)
Posts
For all of us who have managed Temenos T24 implementation projects, we know about the challenges we've faced during implementation. Implementation challenges are not specific to T24 only; but all projects face minor/major challenge(s). The objective of this discussion is to focus on T24 implementation projects and understand, what in your opinion is the most recurring and fatal challenge that you've faced during your T24 implementation? Most importantly, how did you (your team) manage to overcome it? Let's continue Sharing & Learning.
[Mathew@PM4K]
HTTP://WWW.ANISHMATHAIMATHEW.BLOGSPOT.COM
Do join our growing online communities on Blogger, Twitter, Facebook, LinkedIn & NetworkedBlogs. Most importantly, please do come back for more.
![[PM4K] - The Book @ AMAZON](http://1.bp.blogspot.com/-SxDz74KQ5_o/VZszWEf3hnI/AAAAAAAABE4/628Pl2hZxbs/s1600/PM4K%2BBook%2BCover%2Bv3%2BJPG.jpg)
25 Comments:
Before doing the system implementation bank has to do the BPR (Business Process Review) and stream line the workflow. Then only they know their system requirements.
If implementation team has the entire requirement, then it is easy to manage. Need to select proper UAT team and educate all staff members to handle presure if somthing goes wrong.
While knowing the requirements is important, the very most important aspect for succeeding is to have the right business team (with enough power to make decisions) dedicated throughout the project. This will ensure meeting deliverables timely and having a proper knowledge transfer to the team for the benefit of bank, once the project is completed. I always emphasize on this aspect right at the begining, during the project kick off.
I'm facing the problem about BRDs and FSDs documents written in two languages: English for technical people and Spanish por bank's staff (users). The specific problem is that leader users are reviewing Spanish FSDs to sign off but they're asking for modifications/corrections that suppossed they reviewed reading English FSDs, so we the implementation team have to review the original accepted documents, even BRDs to clarify that they asking for new topics not included in the original documents, and this activity is time consuming.
It is important for project management to ensure that everyone involved in the implementation understnds the reasons for the replacement of the legacy system with T24. If there is a failing at this level, there will be a tendency for users to simply give a description of the workflow within the legacy system as a business 'requirement'.
Then the implementation will become a mapping exercise of the old onto the new, and defeat its own object.
I totally agree with Phil here. Users are accustomed to their system and some of them really like it, especially when it is one that they have been developing on for a long time and does exactly what they want. They want to replicate what they have or not to replace it at al.
It is difficult to get them to understand the need for a replacement and it is crucial to try to change their minds in a non-noncofrontational and understanding manner. You need to get them on your side to be able to move things forward smoothly.
If you fail to gain they cooperation you can start expecting huge deviations from the estimates. Besides that, the work environment might start resembling hell.
Ok..my 2c worth. I suggest the project manager builds a relationship with the person in the business that is the influencer / decision maker. They may be different people - but have regular coffee sessions with them. This way you agree on how to manage difficult users / situations before they actually become serious issues. Also - stay impartial in all situations and if someone wants to really bad mouth a fellow team member get both of them into a room and resolve it quickly - otherwise it becomes a drag on the project.
Get a decison making / stakeholder matrix together at the start of the project and most importantly understand how long it takes to have decisions made / ratified.
Last two posts are very much in line with my point: the major issue in every project is FEAR. The decision of purchase and implementing new system is made on the top while the responsibility lies on the regular employees and first-line managers. So, this is the main reason why people try to reproduce 100% what they have now: they will be reporting to their management THE SAME WAY THEY USED TO even after implementing the new system. That's why they request old-fashioned and excessively informative reports, that's why they insist on the specific fields to be added to the system just to meet the reporting requirements, etc.
Now the question obviously comes: what to do? How to avoid this 'material resistance'?
Imho, there are two key issues we should resolve:
(i). management model
(ii). certification
T24 should become a Certified Management Solution - not just accounting or back-office, or middle-office, or even front-office solution, i.e. we should sell a ready-made, out-of-the-box management system. Similar, like the Model Bank offers a 'universal' operational solution, it should also suggest a ready-to-use Management Model: decision making levels, reporting aggregation levels, reporting flows, risk management, etc.
For example: nowadays the modern banking practice is based on the Risk concept. This is, to a major extent, the reason of requesting huge number of reports, most of which just cross-check the information, user input, etc. Bank Management does not trust our solution when it comes to risk issues. We have to convince the banking community that the system is fully compliant with the risk management concept - the same way as we did about accounting: the AUDITOR CERTIFICATION way.
Once it has been confirmed by major auditor companies that T24 correctly reflects the accounting based on GAAP, we may not prove it any more with every next client.
So, I would expect the management consultancy department to do this certification after they create a management model based on the existing T24 modular solution.
To put it simply: we can implement smoothly and effectively only when the Bank's top management have accepted and approved the changes in the Bank's management model and not just paid for the new accounting tool to apply to the old management system.
While writing the comment above Gerhard's post appeared. So, two posts I supported were Paul's and Joel's.
Thank you all for your valuable comments.
@Rasika: I agree if the implementation team has clear requirements, then the project becomes easy to manage, but hope you'd agree that this almost NEVER happens. I agree SCOPE MANAGEMENT definitely holds the key to succes.
@Tarek: Very True. Having the Right Business Team is critical to make correct & timely decision. Just like is the case with JUSTICE; even DECISION Delayed is DECISION Denied (read NOT MADE). You are correct in emphasizing this at the onset of the project. Setting correct USER EXPECTATION is valuable to project success.
@Luis: You're facing quite an issue there! Although I cannot say I've encountered a similar issue with BRDs & FSDs, but I must say, similar challeges are faced when you're dealing with users/people who do not comprehend english well. In the Gulf region, I've faced situations where the BRDs & FSDs were signed off without any objections, but come UAT, none of the requirements the users wanted exists (according to them). To overcome such challenges, we began conducting what we called "User Requirements Sessions" where the SME from the Project Team would walk the key users through the requirements document. This way, we used to ensure that they not only read, but also heard the requirements and agreed to it. PS: Make sure to take attendance when you conduct these "USER REQUIREMENT SESSIONS"!
@Phil-@Joel-@Alexander: Definitely, the "AS-IS" should be clearly differentiated with the "OUGHT-TO-BE" and this needs to be clearly explained to the end users. This is where CHANGE MANAGEMENT comes in. The need to change people's mindset. What's the point of replacing an old legacy system with modern T24, when all you want T24 to do is work like an old legacy system!! This brings us back to the Business Case of the Core Banking Replacement projects. If these issues are not tactically managed, work environment will NOT resemble hell; infact HELL will start to look like a Holiday Destination ;)
@Gerhard: Great point with the stakeholder matrix. To understand and be able to classify your stakeholders is definitely the most tactically important role of a Core Banking Project Manager. At a very high level, I use what I call the STAKEHOLDER MANAGEMENT GRID (as follows):
* HIGH on INFLUENCE & HIGH on INTEREST = INVOLVE
* HIGH on INFLUENCE & LOW on INTEREST = SATISFY
* LOW on INFLUENCE & HIGH on INTEREST = INFORM
* LOW on INFLUENCE & LOW on INTEREST = MONITOR
I would love to hear from you about how you go about with the STAKEHOLDER MANAGEMENT matrix.
Thats a little bit tough task to manage this...
part time jobs
Gentlemen.... Certainly interesting observations on what poses as the No 1 threat. Well i have to agree that all of these are real threats to any project of any size, complexity etc... However what i noticed that none of you made mention of is that of change management. Like the saying goes the fish rots from the head. No Project/ Programme sponsor can hold you accountable for the success of the Endeavour if he(they) don't champion it from day one. He(They) become the catalyst for change. In my experience i've seen both business & technical orientated people become resistant to change. We have to start with the basics first and why i am saying this is because "REMEMBER" we are change peoples lives and the work they work. If you have by now realised that how the process is meant to have worked Vs how it works... you'll come up with a variation that is because users invent creative ways of working with the systems. Therefore the business "IP" walks around with the people how runs the business.
I belive that we all agree that you need specifications, good PL and a strong team etc.
BUT T24 is quite specific in a number of parameters that are unchanable.
In my eyes it is mandatory to agree on each one of them (I've seen to many projects that only realised in final UAT that one of those Parameters is wrongly etc. and had topospone their go live for a couple of monthes....)
The problem is, that Temenos does not have a list of those parameters...
While endorsing most of the comments made by the contributors, I would also like to
point out on the SCOPE CREEP. This happens when the Presales guys sell the product explaining higher level capabilities of the product and further decomposed by the GAP analysis, the third level comes when the techical consultants doing changes which are not documented and this scope creep happens at all levels and especially during UAT testing. Many a time these changes threatens the existing approved design. And finally contributing to the increased man hours.
Also the vendor (Temenos) should develop country specific Reporting tools which will have the regulatory reports for that country.
Hi,
I have a question for the webmaster/admin here at www.anishmathaimathew.blogspot.com.
Can I use some of the information from your blog post above if I give a link back to your site?
Thanks,
Peter
@Peter: Thanks for visiting PM4K. You may feel free to use information from PM4K as long as it has a link back (much appreciated). I look forward to getting the link to where you use it.
Cheers ..Mathew..
This is nice post.It's seems like very beautifully.I enjoy it.
home jobs
This is a good post. I would love to hear from you about how you go about with the STAKEHOLDER MANAGEMENT matrix.
Users are accustomed to their system and some of them really like it, especially when it is one that they have been developing on for a long time and does exactly what they want.
Stay impartial in all situations and if someone wants to really bad mouth a fellow team member get both of them into a room and resolve it quickly - otherwise it becomes a drag on the project.
If implementation team has the entire requirement, then it is easy to manage. T24 correctly reflects the accounting based on GAAP, we may not prove it any more with every next client.
If implementation team has the entire requirement, then it is easy to manage. T24 correctly reflects the accounting based on GAAP, we may not prove it any more with every next client.
I must say that elements you put here look informative. I liked all of them. Keep it up. Thanks a lot for sharing. Looking forward to reading your next post.
Post a Comment