Challenge

I am an IT Project Manager in a boutique Commercial bank of 80 employees. Around 5 people work  in the IT department running the Core Banking system and IT infrastructure. Other than the IT  department it was hard to believe but the rest of the people within the Bank were not tech savvy  meaning that they simply do not know how IT systems work. The issue our IT department had was  that any changes requested to improve the banking process to add value for customers in the Core  Banking system were very expensive, never complete and hardly resulted in any added value to the  bank’s customers. The Bank Directors wanted to find why when budgets were allocated to make  improvement in IT relating to business requirement did not result in significant improvement. I was  allocated a Project to find the cause of the problem and options to how to fix the problem. I was  given a timeframe of 30 days to find the cause of the problem and to bring options on the table.

Selection

As a first step I spoke with heads of the back office team (these teams who in the Bank do the  administration work when entering transaction, orders for the Bank’s Front office operations which  could be a request to execute a FX transaction or provide a trade finance loan to a company) I spoke  with each department around 45 minutes.

In the meetings I could see if I wanted for example a summary of what improvement they wanted in  change request process the department heads were reluctant to provide me anything written. They  were making up excuses that they did not have time to write their improvements ideas as they all  had small teams and they were tied with their operational activities.

When I requested trilateral meeting with the departments the heads all of them complained that for  them making the time to write business specification was not something they wanted and when our  IT team had made business requirements for them and requested their approval they had approved  these requirements without even hardly reading them. Major complain were the documents were  too long and too many technical jargons.

As I recently learned about Scrums I conducted the trilateral meeting using different colour Post IT  notes writing up their frustration with the change process on the meeting room glass walls.

As the discussion was going back and forth the department heads were not losing what they had  earlier proposed as they could see their main points on the POST IT. I asked the department heads

I asked within this meeting whether a visualisation approach could be used to create change  requests. All heads agreed that they could give it a try.

Application

For the first change request a meeting took place between me and the Credit Administration  department for about two hours. The change request was to improve the summary of loan portfolio  that the customer had with the bank. The Credit administration department (two employees) were  surprised that they were asked to draw the layout of the report. The challenge I found here was that  employees were drawing a lot because this was the first time they had a very simple tool where they  could describe what they wanted and apparently they wanted a lot. In this session and the follow-up  session it was important to engage with them but also the same time make them understand that  not everything they wanted could be delivered in one change request. For their change requests  small packets could be made in terms of packets and we could implement the changes in this  manner.

The visualization was done on the whiteboard and the approach was that board was split up in three  sections. The first two sections were proposal from the two employees and third section  collaborative we decided on what columns attributes and how the layout would look like.

In the end three changes request was design which were to provide loan portfolio statement.

Insight

What I was able to see was that by allowing the business users a simple of way of describing their  requirement allowed them to be in control without the tools constraints like not be able to use  PowerPoint or doing graphs or Visio charts to explain the process they wanted to refine.

The Visualization aid (using coloured POST IT, simple drawing which helped the developer as to why  the information was important and very basic calculation being shown) was a very fast and instant  effective way to engage business users in designing the requirement. In the following up discussion  we had taken photos of the visualisation so there was no deviation of what was discussed and as the  business users had created drawings of the change (layout of the report) request follow up  questions or any changes were easy to reference to.

Approach

The Banks  wanted to test this approach for future change requests as the first change request that  was deployed in test environment saw the Credit Administration team engage actively in the testing  process as their approach indicated It was something they had designed and they wanted to see  whether their proposal really were implemented.

The learning for our IT team and for me that as a small bank that most of the operational workers  due to operational pressures simply do not have the time to create the best solution. Large  specification or writing a detailed specification was a Hugh demotivator and an excuse not to engage  with designing the solution. The means to use simple tools like POST IT, drawing to allow them to  express what they wanted is a very simple manner was effective, productive way to engage, reduce  the barrier to express their ideas and allow a simple way to use the visualization for follow up  discussions.


Challenge I am an IT Project Manager in a boutique Commercial bank of 80 employees . Around 5 people work in the IT department running the Core Banking system and IT infrastructure . Other than the IT department it was hard to believe but the rest of the people within the Bank were not tech savvy meaning that they simply do not know how IT systems work . The issue our IT department had was that any changes requested to improve the banking process to add value for customers in the Core Banking system were very expensive , never complete and hardly resulted in any added value to the bank ’s customers . The Bank Directors wanted to find why when budgets were allocated to make improvement in IT relating to business requirement did not result in significant improvement . I was allocated a Project to find the cause of the problem and options to how to fix the problem . I was given a timeframe of 30 days to find the cause of the problem and to bring options on the table . Selection As a first step I spoke with heads of the back office team ( these teams who in the Bank do the administration work when entering transaction , orders for the Bank ’s Front office operations which could be a request to execute a FX transaction or provide a trade finance loan to a company ) I spoke with each department around 45 minutes . In the meetings I could see if I wanted for example a summary of what improvement they wanted in change request process the department heads were reluctant to provide me anything written . They were making up excuses that they did not have time to write their improvements ideas as they all had small teams and they were tied with their operational activities . When I requested trilateral meeting with the departments the heads all of them complained that for them making the time to write business specification was not something they wanted and when our IT team had made business requirements for them and requested their approval they had approved these requirements without even hardly reading them . Major complain were the documents were too long and too many technical jargons . As I recently learned about Scrums I conducted the trilateral meeting using different colour Post IT notes writing up their frustration with the change process on the meeting room glass walls . As the discussion was going back and forth the department heads were not losing what they had earlier proposed as they could see their main points on the POST IT . I asked the department heads I asked within this meeting whether a visualisation approach could be used to create change requests . All heads agreed that they could give it a try . Application For the first change request a meeting took place between me and the Credit Administration department for about two hours . The change request was to improve the summary of loan portfolio that the customer had with the bank . The Credit administration department ( two employees ) were surprised that they were asked to draw the layout of the report . The challenge I found here was that employees were drawing a lot because this was the first time they had a very simple tool where they could describe what they wanted and apparently they wanted a lot . In this session and the follow - up session it was important to engage with them but also the same time make them understand that not everything they wanted could be delivered in one change request . For their change requests small packets could be made in terms of packets and we could implement the changes in this manner . The visualization was done on the whiteboard and the approach was that board was split up in three sections . The first two sections were proposal from the two employees and third section collaborative we decided on what columns attributes and how the layout would look like . In the end three changes request was design which were to provide loan portfolio statement . Insight What I was able to see was that by allowing the business users a simple of way of describing their requirement allowed them to be in control without the tools constraints like not be able to use PowerPoint or doing graphs or Visio charts to explain the process they wanted to refine . The Visualization aid ( using coloured POST IT , simple drawing which helped the developer as to why the information was important and very basic calculation being shown ) was a very fast and instant effective way to engage business users in designing the requirement . In the following up discussion we had taken photos of the visualisation so there was no deviation of what was discussed and as the business users had created drawings of the change ( layout of the report ) request follow up questions or any changes were easy to reference to . Approach The Banks wanted to test this approach for future change requests as the first change request that was deployed in test environment saw the Credit Administration team engage actively in the testing process as their approach indicated It was something they had designed and they wanted to see whether their proposal really were implemented . The learning for our IT team and for me that as a small bank that most of the operational workers due to operational pressures simply do not have the time to create the best solution . Large specification or writing a detailed specification was a Hugh demotivator and an excuse not to engage with designing the solution . The means to use simple tools like POST IT , drawing to allow them to express what they wanted is a very simple manner was effective , productive way to engage , reduce the barrier to express their ideas and allow a simple way to use the visualization for follow up discussions .