Organisation of a Financial Advisory Firm

I had been working on 1 year project that to setup a new Financial Advisory (FA) firm locally in Singapore.  There are lots of discussions with the parent Company, setting up the new FA’s organisation structure, the agents’ structure and roles & responsibilities between FA and parent financial institution.

Lots have been working on and today, I like to share the high level target operational model for this FA.  The organisations required are:

1. Distribution Support (Agency Management, Compensation)
2. New Business
3. Client Services
4. Claims Services
5. Product Development
6. Training & Competency
7. Compliance
8. Finance Accounting
9. Human Resources
10. Risk Management (includes Business Continuity planning)
11. Technology Services
12. Shared Services (outsource, if any)

Poor Requirements, Main Factor for Projects’ Failures

It is no doubt that, in any projects poor requirement gathering results around 60% of projects’ failures that constitute to time and cost deviations.  Unnecessary re-works are done and in cases, customers and the vendors are arguing about change requests, the ‘scope creeps’ they have to pay for the additional work and timeline in which most customers do not want to extend the scope but increase the timeline.

With this ever-increasing competitions, it is harder to change the major stakeholders’ minds to extend projects with these limits.  SCRUM agile methodology is a proven way to ensure the initial business requirements are made, and new changes are built in iterative phases.  Business can also control the scope, the cost and timeline for the delivery upon mutual agreements.  In this case, this is a win-win situation for all.

Hints to Complete Functional Specification Document

Ever experience we can’t finish to get the Customers to agree or sign-off the functional specifications as per planned and instead, it is getting longer and having more details?  In today’s business world, customers are no longer as “dumb” as most IT professionals are thinking of.  With technology advance and lots of training and courses on IT business technology, they are getting to know what they want to get for their projects or products development so that they don’t feel the suppliers are hiding any information.

The above may be true but it may not be necessary to cover everything during user requirement gathering.  This is still a preliminary stage to understand the business flows, expectations and user experiences for the software applications or products and hence put the project schedule on risk if unable to sign-off the requirements to move on to design and development stages.

With that in mind, we can prepare ourselves upfront by anticipating what they are looking for.  Below are the items I have experience and like to share on what to take note of when preparing the sign-off.

1. Use case diagrams – Do not put in too much details e.g. the default selections, exception handling or else it will be too long and it became a technical design flows rather than user flow.
2. Use Cases – no technical details on the functionality.  In most cases, certain level of technical information must be included and defined for the requirement.  If to the stage whereby unable to assess the technical aspect of the requirement,  we will indicate for that requirement’s feasibility will be reviewed during design phase.
3. Screenshots – indicate that wireframes, user interfaces of the software are for illustration purposes.
4. Messages/labels -which are static (labels) and dynamics (normally error or warning messages) to be shorten or rename.  Also to note for any language translations
5. Field lengths – The length, field type (i.e. integer, double, string), default value (if any).  These information mainly covers for input fields.
6. Document layout – make sure to print out the document and ensure the contents can be viewed and aligned correctly.

Something is going wrong with the workshop agenda

After couple of months reviewing the business narrative, we have come back to the beginning stage that we lost track of the whole receiving process of the shipments’ handling for our warehouses.

We are working towards state diagram to inter-relate each operation process and the web service call for each stage.  The problem is who should be the right person to provide this information.  In this morning discussion, everyone has a different view and opinion of the achievements to make for the upcoming the agenda for Country A’s workshop.  We need to include the objectives to be achieved at each timetable and the overall outcome from the workshop so that the participants in that workshop know what they need to prepare before coming into the meeting room.

All of us are stuck with the business narrative, trying to map each paragraph to the exact process flows for each stage of inventory receiving, control, despatch etc, the full end-to-end flow for warehouse management.  We are now worried that the document is incomplete, without knowing if the Operations are aware and comfortable with their defined “To-Be” processes to cater for the new requirements.

With the timeline drawing near, we are not sure how much we can push the country to provide as much updates to the business narrative in order for us to start working on solutioning.   We just have to go along with the flow and do what we can for now.

Implement New Order Type for Cross-Docking

When comes into program’s road-map to determine potential alignments with the Customer.  We have a few new implementations, communicating from all difference sources from the Customer.  We have to have a central contact or a regional alignment personnel to synchronize the initiatives as to manage the IT cost and resources’ availability more efficiently as to align to our Global management’s directions.

For this case, we have 2 new orders types from Customer that are to be handled by our countries’ warehousing operations.  This new initiative impacts the current operations’ processes and the WMS system that we have to manage the inventories and cross-docking operations for this Customer.  The areas that I am working on to fill up the gaps on this implementation are as follows:

1. Understand the source of the order shipment (vendors, 3PLs etc)
2. Where the shipment is going to be lifted from to the destination Hub
3. The receiving process at Origin/manifests
4. Commerical invoices from source
5. The format of the shipping documents
6. The packing labels/Carrier logics
7. Update of shipment milestones
8. Update of shipment delivery dates via Call Center
9. Financial/billing methodology for this order type
10. Freight Management

I am not sure what other areas I may be missing to perform the gap analysis but I believe the above almost covered 80% of information I need to assess on.  Hope whoever see this blog can advise me further what else I need to take note of 🙂

Resource’s Incompetence in Business Analysis

My worst nightmare has begun as I have expected.  As of today, I have not yet received the project activities, schedule and cost’s efforts from Country K and worst of all, I received the feedback from my Regional Business Account Manager that they are expecting “something” from Regional IT.  Country K does not have a Process Manager to work out the “To-Be” processes for the new processes and system enhancements.  Lots of people in this account have either left the Company or move on to a new role.

This issue has highlighted to the Management but there is so much we Regional IT can assist.  We have gathered resources to develop a couple of components but for the business processes there, there is nothing much we can do and we need them to assist the regional development teams to understand the changes to be made on the functionality as to cater to the new processes.

I like to highlight this issue to my Management but on second thoughts I have been asking – what can they do for me at this point?  I foreseen this issue is beyond of my control but I do really need help to clarify this with them to get things move on.  Still I will still go ahead to escalate this to Management and see what are their suggestions.

Is there any way I can help them?  I feel so helpless at this point……

Clarifications on Business Requirement Document

Before starting any development works, we need to have a Business requirement document that outlines the business case/benefits, processes, technology, functionality, data flows, data modeling involved. 

• Business Case
• Business processes that involves for the new changes
• Functional Specification that involves expected system flows, data model for the new changes.

At times, we are overwhelmed with the detailed contents of the document as this document supposed to compile the overall implementation and processes to be delivered from the desired outcomes.  This often results in not understanding what exactly we should be looking out for that have impacts or new changes to the Operations and systems involved.  In most times, we are always stuck on what questions to ask ourselves when trying to understand the documents.

Questions to ask ourselves:

1. Which existing business processes is/are affected by these new changes?
2. How these changes in the existing business processes affect the system design for the new changes?
3. What new technology is being involved and the resources require to manage this new technology?
4. Which data model/mappings is/are affected by these new changes?  How these changes are affected from the changing business processes.
5. Which users are affected and what types of new training to be involved to cater these changes?
6. How the existing administration of the data are being affected?
7. How the existing Service level support affected by these new changes?