Blog

Solution Design & Architecture (SD&A) – Consider this…

When it comes to the design and architecture of enterprise level software solutions, what comes to mind?

What is Solution Design & Architecture:

SolutionDesign and Architecture (SD&A) is an in-depth IT scoping and review process that bridges the gap between your current IT environments, technologies, and the customer and business needs in order to deliver maximum return-on-investment. A proper design and architecture document also documents the approach, methodology and required steps to delivery the solution.

SD&A are actually two distinct disciplines. Solution Architect’s, with a balanced mixed of technical and business skills, write up the technical design of an environment and work out how to achieve a solution from a technical perspective. Solution Designers put the solution together and price it up based from assistance from the architect.

A solutions architect needs significant people and process skills. They are often in front of management, trying to explain a complex problem in laymen’s terms. They have to find ways to say the same thing using different words for different types of audiences, and they also need to really understand the business’ processes in order to create a cohesive vision of a usable product.

Solution Architect focuses on: 

  • market opportunity
  • technology and requirements
  • business goals
  • budget
  • project timeline
  • resourcing
  • ROI
  • how technology can be used to solve a given business problem 
  • which framework, platform, or tech-stack can be used to create a solution 
  • how the application will look, what the modules will be, and how they interact with each other 
  • how things will scale for the future and how they will be maintained 
  • figuring out the risk in third-party frameworks/platforms 
  • finding a solution to a business problem

Here are some of the main responsibilities of a solutions architect:

Ultimately, the Solution Architect is responsible for the vision that underlies the solution and the execution of that vision into the solution.

  • Creates and leads the process of integrating IT systems for them to meet an organization’s requirements.
  • Conducts a system architecture evaluation and collaborates with project management and IT development teams to improve the architecture.
  • Evaluates project constraints to find alternatives, alleviate risks, and perform process re-engineering if required.
  • Updates stakeholders on the status of product development processes and budgets.
  • Notifies stakeholders about any issues connected to the architecture.
  • Fixes technical issues as they arise.
  • Analyses the business impact that certain technical choices may have on a client’s business processes.
  • Supervises and guides development teams.
  • Continuously researches emerging technologies and proposes changes to the existing architecture.

Solution Architecture Document:

The Solution Architecture provides an architectural description of a software solution and application. It describes the systems and it’s features based on the technical aspects, business goals, and integration points. It is intended to address a solution to the business needs and provides the foundation/map of the solution requirements driving the software build scope.

High level Benefits of Solution Architecture:

  • Builds a comprehensive delivery approach
  • Stakeholder alignment
  • Ensures a longer solution lifespan with the market
  • Ensures business ROI
  • Optimises the delivery scope and associated effectiveness
  • Easier and more organised implementation
  • Provides a good understanding of the overall development environment
  • Problems and associated solutions can be foreseen

Some aspects to consider:

When doing an enterprise level solution architecture, build and deployment, a few key aspects come to mind that should be build into the solution by design and not as an after thought…

  • Solution Architecture should a continuous part of the overall innovation delivery methodology – Solution Architecture is not a once-off exercise but is imbedded in the revolving SDLC. Cyclically evolve and deliver the solution with agility that can quickly adapt to business change with solution architecture forming the foundation (map and sanity check) before the next evolution cycle. Combine the best of several delivery methodologies to ensure optimum results in bringing the best innovation to revenue channels in the shortest possible timeframe. Read more on this subject here.
  • People – Ensure the right people with the appropriate knowledge, skills and abilities within the delivery team. Do not forget that people (users and customers) will use the system – not technologists.
  • Risk – as the solution architecture evolves it will introduce technology and business risks that must be added to the project risk register and addressed to mitigation in accordance with the business risk appetite.
  • Choose the right software development tech stack that is well established and easy supported, scalable and yet power enough to deliver a feature rich solution that can easily integrate into complex operational estates and cyber and information security requirements. You can read more on choosing a tech stack here. Most tech-stacks has Solution Frameworks that outline key design options and decision when doing solution architecture. Choosing the right tech-stack is one of the most fundamental ways to future-proof the technology solution.
  • Modular approach – using a service oriented architecture (SOA) ensure the solution can be scaled up and down easily by using independently functioning macro and micro-services. Each service must be clearly defined with input, process, output parameters that aligns with the integration standard established for the platform. This SOA also assist in overall information security and fault finding in case something goes wrong and makes the developed platform agile to adapt to continuous business environment and market changes.
  • Customer data at the heart of a solution – Be clear on Master vs Slave customer records and ensure the needed integration between master and slave data within systems and platforms with the needed security applied to ensure privacy and data integrity. Establish a Single Customer View (single version of the truth) from the design off-set. Ensure data is handled within the solution according to the regulations as outlined in the Data Protection Act and recently introduced GDPR and data anonymisation and retention policy guidelines.
  • Platform Hosting & Infrastructure – What is the intended hosting framework, will it by private or public cloud, running in AWS or Azure – all important decisions that can drastically impact the solution architecture.
  • Scalability – who is the intended audience for the different macro services within the solution – how many consecutive users, transactions, customer sessions, reports, dashboards, data imports & processing, data transfers, etc…? As required, ensure the solution architecture accommodate the capability for the system to monitor usage and automatically scale horizontally (more processing/data (hardware) nodes running in parallel without dropping user sessions) and vertically (adding more power to a hardware node).
  • Information and Cyber Security – Various security precautions, guidelines and best practices should be imbedded within the software development of the solution by design and should be articulated within the solution architecture, infrastructure and service software code.
  • Integration – data exchange, user interface, compute and storage components of the platform and how the different components inter-connects through secure connections.
  • Customer Centric & Business Readiness – from a customer and end-user perspective what’s needed to ensure easy adoption (familiarity) and business ramp-up to establish a competent level of efficiency before the solution is deployed and go-live. UX, UI, UAT, Regression Testing, Training Material, FAQs, Communication, etc…
  • Enterprise deployment – Involvement of all IT and business disciplines i.e. Business readiness (covered above), Network, Compute, Cyber Security, 
  • Application Support – Involve the support team during product build to ensure they have input and understanding of the solution to provide SLA driven support at to business and IT operations when the solution goes live. 
  • Business Continuity – what is required from an IT infrastructure and platform/solution capability perspective to ensure the system is always available (online) to enable continuous business operations?

Speak to Renier about your solution architecture requirements. With more than 20 years of enterprise technology product development experience, we can support your team toward delivery excellence.

Also Read:

12 Useful Psychological Hacks

#1. If you want to know about something from someone , ask them a question and when they are done answering , keep silent and maintain an eye contact. They will tell you some more stuff, almost everything.

#2. When you try to convince someone over something, make sure they are sitting and you are standing. This makes them believe you sooner.

#3. The key to confidence is walking into a room and assume that everyone already likes you.

#4. Refer to people you’ve just met by their name. People love being referred to by their name and it will establish a sense of trust and friendship right away. Example: “Nice to meet you Alex. So, Alex how do you know John?” And continue to repeat name throughout the conversation.

#5. If someone is attracted to you, their eyes start blinking more than usual during a conversation with you.

#6. Spot the difference between a fake smile and a real one. You can find out if someone is smiling for real or faking it by looking at their eyes. Wrinkles form near eye corners when the smile is genuine.

#7. Pay attention to people’s feet. To know if someone is interested in a conversation look at their feet, if they are pointing towards you, they are. If they are pointing sideways or any other direction, they aren’t. Feet don’t lie.

#8. When at a party or a meeting. When at a party or a meeting, crack a joke and observe the people who are laughing around you. People who feel close to each other will be looking at each other. This is useful for discerning out friendships and other relationships.

#9. The life hack to make people do what you want them to do. Offer someone a choice instead of a command. For example, instead of saying drink your milk to a toddler, ask which mug would he/she like to drink milk from. This gives the person a sense of control hence produces a higher chance of a better outcome.

#10 How to win an argument?. If the person arguing loses his temper and starts shouting, natural human tendency is to shout back. DON’T! Stay calm and reply in silence. Try it! It works.

#11. Mirror people’s body language to build up trust. If you subtly mimic the body language of the person you’re talking to, you can effectively build up trust with them. By mirroring the way they speak and how they move they’ll like you more, because, to them, it will seem as if you are pretty good compatible.

#12 Inception To plant a seed of idea in someone’s mind, ask them to not think of a particular thing at all. Let’s say I ask you to NOT think about motorbikes. What are you thinking of?

RPA – Robotic Process Automation

Robotic process automation (RPA), also referred to as software robots, is a form of business process automation (BPA) – also now as Business Automation or Digital Transformation – where complex business processes are automated using technology enabled tools harnessing the power of Artificial intelligence (AI).

Robotic process automation (RPA) can be a fast, low-risk starting point for automating repettitive processes that depend on legacy systems. Software bots can pull data from these manually operated systems (most of the time without an API) into digital processes, ensuring faster and more efficient and accurate (less user error) outcomes. 

Workflow vs RPA

In traditional workflow automation tools, a system developer produces a list of actions/steps to automate a task and define the interface to the back-end system using either internal application programming interfaces (APIs) or dedicated scripting language. RPA systems, in contrast, compile the action list by watching the user perform that task in the application’s graphical user interface (GUI), and then perform the automation by repeating those tasks directly in the GUI, as if it is manually operated.

Automated Testing vs RPA

RPA tools have strong technical similarities to graphical user interface testing tools. Automated testing tools also automate interactions with the GUI by repeating a set of actions performed by a user. RPA tools differ from such systems in that they allow data to be handled in and between multiple applications, for instance, receiving email containing an invoice, extracting the data, and then typing that into a financial accounting system.

RPA Utilisation

Used the right way, though, RPA can be a useful tool in your digital transformation toolkit. Instead of wasting time on repetitive tasks, your people are freed up to focus on customers or subject expertise bringing product & services to market quicker and provide customer outcomes quickly – all adds up to real tangible business results.

Now, let’s be honest about what RPA doesn’t do – It does not transform your organisation by itself, and it’s not a fix for enterprise-wide broken processes and systems. For that, you’ll need digital process automation (DPA).

Gartner’s Magic Quadrant: RPA Tools

The RPA market is rapidly growing as incumbent vendors jockey for market position and evolve their offerings. In the second year of this Magic Quadrant, the bar has been raised for market viability, relevance, growth, revenue and how vendors set the vision for their RPA offerings in a fluid market.

Choosing the right RPA tool for your business is vital. The 16 vendors that made it into the 2020 Gartner report is marked in the appropriate quadrant below.

The Automation Journey

To stay in the race, you have to start fast. Robotic process automation (RPA) is non-invasive and lightning fast. You see value and make an immediate impact.

Part of the journey is not just making a good start with RPA implementations but to put the needed governance around this technology enabler. Make sure you can maintain the automated processes to quickly adapt to changes, integrate with new applications, align with continuously changing business processes while making sure that you can control the change and clearly communicate it to all needed audiences.

To ensure that you continuously monitor the RPA performance you must be able to measure success. Data gathered throughout the RPA journey and then converted through analytics into meaningful management information (MI). MI that enables quick and effective decisions – that’s how you finish the journey.

Some end-to-end RPA tools cover most of the above change management and business governance aspects – keep that in mind when selecting the right tool for your organisation.

So, do you want to stay ahead of your competition? Start by giving your employees robots that help them throughout the day.

Give your employees a robot

Imagine if, especially in the competitive and demanding times we live today, you could give back a few minutes of time of every employee’s day. You can if you free them from wrangling across systems and process siloes for information. How? Software robots that automate the desktop tasks that frustrate your people and slow them down. These bots collaborate with your employees to bridge systems and process siloes. They do work like tabbing, searching, and copying and pasting – so your people can focus on your customers.

RPA injects instant ROI into your business.

Also read:

Fundraisers tackle Route 66 – without even leaving home

Renier Botha joined the Shawbrook Bank staff who have ‘virtually’ tackled one of the most iconic road networks in the world to raise vital funds for frontline workers in the NHS.

The 14-strong group of colleagues decided to embrace lockdown boredom head-on by sign- ing up for the online ‘Route 66 Virtual fitness challenge.’

Hosted by the Conqueror web- site, the challenge saw partici- pants complete the 2,280-mile route online by recording the completion of physical walking, jogging and running exercises at home.

Travelling virtually from Chi- cago to Los angeles, the group gave themselves a three-month target to complete the entire length of the Route 66 highway.

However, they smashed that tar- get in impressive style, completing the gruelling trek in less than a month – and raising £2,940 for the NHS at the same time.

Gareth McHenry – who launched the charity effort before roping in his colleagues – said the idea initially came about to relieve the boredom of lockdown.

Gareth, head of delivery and innovation at Shawbrook Bank, said: “Lockdown has taken its toll on lots of people across the UK – not just within Shawbrook.

“So we decided as a group to have a think of activities that we could do online that would help alleviate the boredom and the monotony of lockdown and at the same time help us stay fit both mentally and physically.

“Route 66 is one of the most iconic – if not thee most iconic – highway in the world and so we felt this would be a great project to start off with. We decided to go for it, and to try and raise some funds for our NHS frontline heroes at the same time and it just grew arms and legs from there.

“We have a group Slack channel that we use to communicate and from within that we just egged each other on. We initially gave ourselves a three-month target to complete all 2,280 miles but we absolutely smashed that within a month – raising almost £3,000 in the process.

“all in all, it’s been a very worth- while exercise and we’re all delighted with it.”

The Conqueror website describes the virtual Route 66 trek as the “ultimate running, cycling and walking challenge’”

But after just six days the team from Shawbrook had managed to cover more than 400 miles.

Gareth added: “this gave the team a little bit of focus out with work and helped us re-create a bit of workplace atmosphere at the same time. after enjoying it so much we’re now trying to plan our next challenge.”

The successful team from Shawbrook Bank included Gareth McHenry, alex Richardson, Chris Kerr, Edward Grainge, Giselle Kelly, James Popham, John Culli- nane, Jonathan Hotchkiss, Nigel Cooper, Patrick Coughlan, Renier Botha, Stephen Birrell, Brendan Ellis and John Kelly.

Read article Shawbrook-Route 66 Surrey Mirror

The Route 66 Virtual Challenge is hosts by “the conqueror”

Seven Coaching Questions

Question 1: “What’s on your mind?” 

A good opening line can make all the difference (just ask Charles Dickens, the Star Wars franchise, or any guy in a bar). The Kickstart Question starts fast and gets to the heart of the matter quickly. It cuts to what’s important while side stepping stale agendas and small talk. 

Question 2: “And what else?” 

The AWE Question keeps the flame of curiosity burning. “And what else?” may seem like three small words, but it’s actually the best coaching question in the world. That’s because someone’s first answer is never the only answer — and rarely the best answer. There are always more answers to be found and possibilities to be uncovered. Equally as important, it slows down the question asker’s “advice monster” — that part of every manager that wants to leap in, take over, and give advice/be an expert/solve the problem. 

Question 3: “What’s the real challenge here for you?” 

This is the Focus Question. It gets to the essence of the issue at hand. This question defuses the rush to action, which has many people in organizations busily and cleverly solving the wrong problems. This is the question to get you focused on solving the real problem, not just the firstproblem. 

The first three questions combine to form a powerful script for any coaching conversation, performance-review formal, or water-cooler casual. Start fast and strong, provide the opportunity for the conversation to deepen, and then bring things into focus with the next questions. 

Question 4: “What do you want?” 

This is the Foundation Question. It’s trickier than you think to answer, and many disagreements or dysfunctional relationships will untangle with this simple but difficult exchange: “Here’s what I want. What do you want?” It’s a basis for an adult relationship with those you work with, and a powerful way to understand what’s at the heart of things. 

Question 5: “How can I help?” 

It might come as a surprise that sometimes managers’ desire to be helpful can actually have a disempowering effect on the person being helped. This question counteracts that in two ways. First, it forces the other person to make a clear request, by pressing them to get clear on what it is they want or need help with. Second, the question works as a self-management tool to keep you curious and keep you lazy — it prevents you from leaping in and beginning things you think people want you to do. 

Question 6: “If you’re saying yes to this, what are you saying no to?” 

If you’re someone who feels compelled to say “yes” to every request or challenge, then this question is for you. Many of us feel overwhelmed and overcommitted; we’ve lost our focus and spread ourselves too thin. That’s why you need to ask this Strategic Question. A “yes” without an attendant “no” is an empty promise.

Question 7: “What was most useful for you?” 

Your closer is the Learning Question. It helps finish the conversation strong, rather than just fading away. Asking “What was most useful for you?” helps to reinforce learning and development. They identify the value in the conversation — something they’re likely to miss otherwise, and you get the bonus of useful feedback for your next conversation. You’re also framing every conversation with you as a useful one, something that will build and strengthen your reputation. 

From the book: The Coaching Habit: Say Less, Ask More & Change the Way Your Lead Forever

Digital Strategy & the Board

Digital Strategy is a plan that uses digital resources to achieve one or more objectives. With Technology changing at a very fast pace, Organisations have many digital resources to choose from.

Digital Resources can be defined as materials that have been conceived and created digitally or by converting analogue materials to a digital format for example:

  • Utilising the internet for commerce (web-shops, customer service portals, etc…)
  • Secure working for all employees from anywhere via VPN
  • Digital documents, scanning paper copies and submitting online correspondence to customers i.e. online statements and payment facilities via customer portals
  • Digital resources via Knowledge Base, Wiki, Intranet site and Websites
  • Automation – use digital solutions like robotics and AI to complete repetitive tasks more efficiently
  • Utilising social media for market awareness, customer engagement and advertising

A Digital Strategy is typically a plan that helps the business to transform it’s course of action, operations and activities into a digital nature by utilising available applicable technology.

Many directors know that digital strategies, and there related spending, can be difficult to understand. From blockchain and virtual reality to artificial intelligence, no business can afford to fall behind with the latest technological innovations that are redefining how businesses connect with their customers, employees, and myriad of other stakeholders. Read this post that covers “The Digital Transformation Necessity“…

As a Board Director what are the crucial factors that the Board should consider when building a digital strategy?

Here are five critical aspects, in more detail, and the crucial things to be conscious of when planning a digital transformation strategy as part of a board.

Stakeholders

A stakeholder, by definition, is usually an individual or a group impacted by the outcome of a project. While in previous roles you may have worked with stakeholders at senior management level, when planning a digital strategy, it’s important to remember that your stakeholders could also include customers, employees or anyone that could be affected by a new digital initiative.

Digital strategies work from the top down, if you’re looking to roll out a digital transformation project, you need to consider how it will affect every person inside or outside of your business.

Investment

Digital transformation almost always involves capital and technology-intensive investments. It is not uncommon for promising transformation projects to stall because of a lack of funds, or due to technology infrastructure that cannot cope with increased demands.

Starting a budgeting process right at the start of planning a digital transformation project is essential. This helps ensure that the scope of a project does not grow beyond the capabilities of an enterprise to fund it. A realistic budgeting and funding approach is crucial because a stalled transformation project creates disruption, confusion and brings little value to a business.

Communications

From the get-go, any digital strategy, regardless of size, should be founded on clear and constant communication between all stakeholders involved in a project. This ensures everyone is in the loop on the focus of the project, their specific roles within it, and which processes are going to change. In addition, continuous communication helps build a spirit of shared success and ensures everyone has the information they need to address any frustrations or challenges that may occur as time passes. When developing an effective communication plan, Ian’s advice is to hardly mention the word digital at all.

The best digital strategies explain what digital can do and also explain the outcomes. Successful communication around digital strategies uses language that everyone can understand, plain English, no buzzwords, no crazy acronyms and no silly speak.

Also read “Effective Leadership Communication” which covers how you can communicate effectively to ensure that everyone in the team are on the same page.

Technology

While there are many technologies currently seeing rapid growth and adoption, it doesn’t necessarily mean that you will need to implement all of them in your business. The choice of technology depends upon the process you are trying to optimise. Technology, as a matter of fact, is just a means to support your idea and the associated business processes.

People often get overwhelmed with modern technologies and try to implement all of them in their current business processes. The focus should be on finding the technologies that rightly fit your business objectives and implement them effectively.

Never assume that rolling out a piece of technology is just going to work. When embarking on a digital project, deciding what not to do is just as important as deciding what to do. Look at whether a piece of technology can actually add value to your business or if it’s just a passing trend. Each digital project should hence be presented to Board with a business case that outlines the business value, return on investment and the associated benefits and risks, for board consideration.

Measurement

No strategy is complete without a goal and a Digital Strategy is no different. To measure the effectiveness of your plan you will need to set up some key performance indicators (KPIs). These metrics will demonstrate the effectiveness of the plan and will also guide your future decision making. You will need to set up smart goals that have clear achievable figures along with a timeline. These goals will guide and optimise the entire execution of a transformation project and ensure that the team does not lose focus.

Any decent strategy should say where we are now, where we want to get to and how we’re going to get there, but also, more importantly, how are we going to monitor and track against our progress.

Also Read

 

Risk Management – for NEDs

Arguably the most significant adjustment to the NED role over the past seven years is that all NEDs must now be well versed in identifying and managing all forms of risk – operational, financial and reputational…

As a Chairman once described: “Risk is a massive issue now: You need to understand the risks and be clear about what the board is doing about mitigating those risk.”

So, how can you ensure that risks are being articulated appropriately and how can you probe into how risks are being mitigated, irrespective if risk management is well established within an industry or not? In the first part of this article I give some steer on how you can assess current risk management practises (governance) and the latter part covers some best practises.

Risk Maturity

If not already done within the company, you could do a Risk Maturity Assessment which gives an indication of the organisation’s engagement with risk management.

There are various models, usually with five levels of maturity (see the 5 Level Maturity Model in diagram below): from an immature Level 1 organisation where there are no formal risk management policies, processes or associated activities, tools or techniques, through a Level 2 managed organisation where policies are in place but risk reviews are generally reactive, all the ay up to the mature or ‘risk intelligent’ Level 5 enterprise where the risk management tone is set at the top and built into decision making, with risk management activities proactively embedded at all levels of the organisation.

Maturity - 5 Levels

     5 Level Maturity Model 

The outcome of such an assessment will give you clear indication of the risk management maturity level of the organisation. Dependant on how that aligns with the Shareholders’ and Board’s expected level, the needed change actions can be initiated to mature the organisation to the expected level. It will also give you measure of clarity of the rigour of process and review that is likely to have gone into the risk reporting that you see as a Board.

Risk Score/Rating Matrix

As risks are identified, logged in the Risk Register and then assessed based on likelihood of it happening and the impact to the business if it should happen, a Risk Scoring Matrix (with preferably a 5 point scal as per diagram below) is very useful to assign a Risk Score to each risk.

The higher the score the higher the priority of mitigating the risk should be.

RISK Matrix

Risk Score Matrix

As a NED you need to assess the completeness of the Key Risks in the Risk Register. Engaging with the executives prior board meetings goes a long way to get input and a feel for risks existing on the floor (day to day running/operations) of the business. You should also ask if there is something that you are talking about in every meeting that either is not on the risk register, or is rated as a low risk?  If that is true, then you need to explore why you are talking about it as a Board but management are not giving it greater focus.

Risk Heat Chart

A heat chart (as per diagram below) enables a holistic view of risks with high scoring risks in the top right (coloured red) corner and low risks in the bottom left corner (coloured green).Risk-HeatMap

   Risk Heat Map

For a board to get an overview of what the key risks are, I don’t think you can beat a heat chart.

As a NED, you can use this to sense check: Are the risks in the top quadrants, the Red Risks, the ones that the Board feel are the highest risk? Are you talking about these risks regularly and challenging the business on what mitigating actions they are doing to reduce them?

Approach on Risk Review

The popular parlance these days is a ‘deep dive’ into the highest risks, usually undertaken by the Audit Committee.

Apart from the “deep dive’ into risks usually undertaken by the Audit Committee you, as a NED, want to do your own exploring, below is an approached…

1. Current Risk Score

What is the justification for the current rating – does this feel right? The impact should be measured by the potential impact of the risk on strategic objectives, and is usually quite easy to define, but likelihood can be more subjective.

Also known as the mitigated risk rating, the current rating should recognise mitigations or controls that are already in place, and how effective these are.

2. Target Risk Score

What is a reasonable target risk rating for this risk, ie where are we trying to get to?

As a Board, you need to set the risk appetite (which equates to target risk ratings).  This may vary by the type of risk, for example, targeting a very low risk rating might be necessary on something that is a matter of compliance or safety, but in commercial matters, the trade-off between risk and reward needs to be considered, so a higher risk appetite is likely to be acceptable.

There won’t be a limitless budget to spend on mitigating every risk to a minimal level, so as a Board you will have to decide what level of risk you are comfortable with; and where the balance sits between reducing the risk and the cost of mitigation.  Why would you spend more on mitigations than the financial impact of the risk crystallising?

3. Mitigating actions

How are you going to get to your target level of risk?  Planned mitigating actions should drive the risk rating to its target level.  This is a focus area for audit committee deep dives – what actions are planned, and will they be sufficient to bring you to your target risk rating?  Progress on these actions should be monitored regularly – if no progress, ask if this risk being taken seriously enough? Or is it not as big a risk as you first thought?

Good risk management should aid decision making, avoid or minimise losses, but also identify opportunities.

Let’s look now into Risk Mitigation in more detail…

Approach on Risk Mitigation

Risk mitigation can be defined as taking steps to reduce adverse effects and impact to the business while reducing the likelihood of the risk.

There are four types of risk mitigation strategies that hold unique to Business Continuity and Disaster Recovery. When mitigating risk, it’s important to develop a strategy that closely relates to and matches your company’s risk profile.

four types of risk mitigation

Risk Acceptance

Risk acceptance does not reduce any effects however it is still considered a strategy. This strategy is a common option when the cost of other risk management options such as avoidance or limitation may outweigh the cost of the risk itself. A company that doesn’t want to spend a lot of money on avoiding risks that do not have a high possibility of occurring will use the risk acceptance strategy.

Risk Avoidance

Risk avoidance is the opposite of risk acceptance. It is the action that avoids any exposure to the risk whatsoever. It’s important to note that risk avoidance is usually the most expensive of all risk mitigation options.

Risk Limitation/Reduction

Risk limitation is the most common risk management strategy used by businesses. This strategy limits a company’s exposure by taking some action. It is a strategy employing a bit of risk acceptance along with a bit of risk avoidance or an average of both. An example of risk limitation would be a company accepting that a disk drive may fail and avoiding a long period of failure by having backups.

Risk Transference

Risk transference is the involvement of handing risk off to a willing third party. For example, numerous companies outsource certain operations such as customer service, payroll services, etc. This can be beneficial for a company if a transferred risk is not a core competency of that company. It can also be used so a company can focus more on their core competencies.

All of these four risk mitgiation strategies require montioring. Vigilence is needed so that you can recognize and interrperet changes to the impact of that risk.

 

Project Sponsorship

There are multiple aspects that contribute to a successful project, for example the right people, proper planning, governance, clear roles and responsibilities, but to mention a few. You could argue all equally important but one of the most important aspects that are often overlooked is the position of the Project Sponsor.

In my experience, the Sponsor holds one of the most important roles in terms of project success or failure. An involved sponsor who really is vested in the success of the project, will bring drive and energy to the project at a senior executive level – especially needed when the going gets tough.

The Project Sponsor takes ownership for the project goals, provides overall direction for the project and is the owner of the final product/deliverable.

Project Sponsor – Definition

In PRINCE2 it is not a defined role. PRINCE2 separately defines the “Project Executive” and the “Senior User” – two of the three core elements of the Project Board. For simpler projects these roles may well be combined and this then aligns closely with the general usage of the term Project Sponsor.

The APM Body of Knowledge characterises the Project Sponsor as the individual for whom the project is undertaken and who is the primary risk taker. The Sponsor is a member of the Steering Group which provides strategic direction and will include senior managers and, sometimes, key stakeholders.

The PMI PMBOK Guide talks about project sponsors and project initiators: the project initiator authorises the initiation of a project and the project sponsor provides the financial resources, in cash or in kind for the project. Again, these roles may often be assumed by a single individual.

Who can be a Project Sponsor

It is unusual for Project Sponsors to be full time project professionals. It is more likely that they are drawn from the management team of the business – perhaps as an interested “user”. For major projects it may be the CEO or CIO which assumes the role of Sponsor. It is preferable that the individual brings relevant experience and wields the authority and organisational ability to make things happen.

A sponsor needs to be:

  • a business leader and decision-maker with the credibility to work across corporate and functional boundaries;
  • an enthusiastic advocate of the work and the change it brings about;
  • prepared to commit time and support to the role;
  • sufficiently experienced in P3 to judge if the work is being managed effectively and to challenge P3 managers where appropriate.

Project Sponsor vs Other Project Roles

Project Sponsor vs. Project Owner

The project sponsor is a person.  The project owner is the organization that performs the project and receives its deliverables.  Normally the project sponsor is employed by the project owner organisation.

Project Sponsor vs. Project Manager

The project sponsor is one (and only one) level above the project manager.  While the project manager is responsible for the day to day operations of the project, the project sponsor seeks to promote the project to keep it high on the priority list, ensures the resources are in place to perform the project, and approves changes to the project.

Project Sponsor Project Manager
Day to Day management of project work No Yes
Project Deliverables Accepts Produces
Funding Approves Requests

The two main differences between project sponsorship and project management 

    1. Project sponsorship includes the identification and definition of the project whereas project management is concerned with delivering a project that is already defined, if only quite loosely.
    2. The project sponsor is responsible for the project’s business case and should not hesitate to recommend cancellation of the project if the business case no longer justifies the project.

Quick look at Other Project Roles:

    • Project Manager:  Responsible for the day to day project work, keeping the project on schedule and budget.  They report to the Project Sponsor.
    • Project Team:  The people who perform the technical project work and produce the deliverables.  They report to the project manager.
    • Customers/Users:  The people who use the project deliverables to improve their lives or work.  They are sometimes involved directly within the project in the form of focus groups or test subjects.
    • Vendors:  The people and organizations the project procures to provide products and/or services to fill technical gaps in the project team’s knowledge or ability, or to enhance the quality of the final product.
    • Business Partners:  The people or organizations that the project owner partners with to fulfill a specific role like installation, training or support.
    • Functional Managers:  The managers of technical groups (departments) within the owner organization, who often supply technical expertise to the project.
    • External Stakeholders:  Most project have stakeholders who are affected by the project, like government regulatory agencies, adjacent landowners, and the like.

Sponsor Responsibilities

The role of project sponsor is critical to ensuring the success of projects – therefore, when initiating a new project, you need to define the project sponsor taking into account the importance of project sponsorship. A project sponsor is to be involved from project initiation to project end. They represent the business side of the project.  They were probably involved when the project was being conceived and advocated for its inception before a project manager was assigned.

Further the sponsor is critical to strategic planning, high project sustainability, and successful implementation of project objectives. The role of project sponsor covers the financial and organizational responsibilities and activities that are directed to quick and decisive governance of the project.

The project sponsor is one, and only one, level above the project manager.  They do not manage the day to day operations of the project but they ensure the resources are in place, promote the project, and hold overall responsibility for the project’s success.

A good sponsor performs different functions during the project life cycle, serving as mentor, catalyst, motivator, barrier buster, and boundary manager. Most of the sponsor responsibilities are covered below:

  • The sponsor is the link between the project manager and senior managers, lead negotiations to gain and ensure stakeholder consensus.
  • Champion/Promotion: The project sponsor is the best ‘project seller’ that champions the project thought the business. The sponsor promotes and defends the project in front of all other stakeholders. They are the project champion that attempts to keep the project at the highest priority within the organisation.
  • Informing:  They receive project status updates from the project manager and disseminate the information to the relevant executives.
  • Project Charter:  This document officially creates the project and assigns the project manager.  It falls directly within the project sponsor’s responsibility.
  • Authorisation: They authorise the project and assign the project manager. They approve the project management plan and are kept aware of how the project is managed.
  • Scoping:  They are generally responsible for determining the initial project scope, although the project manager is ultimately responsible for the official project scope within the project management plan.
  • Goals: The Sponsor should ensure that the business need is valid and correctly prioritised within the project.
  • Communication: Clearly communicate on aspects of the project with stakeholder groups and senior management.
  • Keeping to Schedule: The Sponsor is heavily involved in ensuring that the project is kept to the original schedule along with the Project Manager. In order to manage the schedule the Sponsor and Project Manager should meet frequently and review the timeline.
  • Changes: A project can experience changes at any time. The Sponsor needs to ensure that these changes are properly managed to ensure that they don’t have any negative impact on the project.
  • Resolve Risks & Issues: Some issues are out of the reach of the Project Manager such as decisions on changes and conflicting objectives. The Sponsor takes control of these issues and ensures that they are solved efficiently and effectively.
  • Support: The Project Manager needs consistent support during a project. The Sponsor is on hand to provide this support in the form of mentoring, coaching and leadership. The Sponsor also supports the Project Team especially in terms of scope clarification, progress management and guidance.
  • Reporting: Assistance for the PM with appraisal and reporting.
  • Funding: They are responsible for negotiations to ensure funding is in place and approving changes to the project budget.
  • Leadership: Provide direction and guidance for project empowerment, key business strategies and project initiatives.
  • ROI & Benefits: As owner of the business case, the project sponsor is responsible for qualifying and overseeing the delivery of the benefits (the benefits realisation) as well as to identify project critical success factors and approve deliverables.
  • Identify members of Steering Committee and chair these Steerco meetings.
  • Involve stakeholders in the project and maintain their ongoing commitment to the project through using communication strategies and project management planning methods
  • Receiving:  Evaluate the project’s success on completion – The project sponsor receives the project deliverables from the project manager, approves them, and integrates them into the owner organization.

According to the Project Management Institute (PMI), the project sponsor role can be broken into three parts: vision, governance and value or benefits realization. They break those down in the following way:

Vision

    • Makes sure the business case is valid and in step with the business propositio
    • Aligns project with business strategy, goals and objective
    • Stays informed of project events to keep project viable
    • Defines the criteria for project success and how it fits with the overall business

Governance

    • Ensures project is properly launched and initiated
    • Maintains organizational priorities throughout project
    • Offers support for project organization
    • Defines project roles and reporting structure
    • Acts as an escalation point for issues when something is beyond the project manager’s control
    • Gets financial resources
    • Decision-maker for progress and phases of project

Values & Benefits

    • Makes sure that risks and changes are managed
    • Helps to ensure control and review processes
    • Oversees delivery of project value
    • Evaluates status and progress
    • Approves deliverables
    • Helps with decision-making
    • Responsible for project quality throughout project phases

Common reasons why the Sponsor lets down the project:

Many organisations invest heavily in project management training but are blind to the benefits of having project leaders who truly understand how projects differ from other management activities. Business are letting a project down if the sponsor:

    • is reassignment in the organisation, or distraction by other priorities.
    • is micro managing which can disrupt project manager confidence and authority.
    • fails to understand the project process and responsibilities.

The chances are that if an inappropriate project sponsor has been chosen,

    • the effectiveness of the role is reduced,
    • the project is not funded sufficiently,
    • and the overall success of the project is likely to turn into failure.

In fact, any project which is initiated without an appropriate degree of executive sponsorship (executive sponsor) stands an high likelihood of failure.

Sponsorship: project, programme or portfolio

Project

The role of the project sponsor starts before the appointment of the project manager. It continues beyond project closure and the departure of the project manager. So the sponsorship role covers the whole project life cycle.

The project sponsorship role will often be taken by the programme manager where the project is part of a programme.

Programme

The scale of programmes will often require a sponsor to be supported by a group of senior managers who perform some sponsorship duties. However, ultimate accountability will lie with the programme sponsor.

The programme manager should also be a competent project sponsor and will often perform that role for some, or all, of the programme’s component projects.

Portfolio

Sponsorship of a portfolio of projects and programmes will be undertaken by a senior executive with the necessary status, credibility and authority. This may well be a main board member, or even the CEO of the organisation. The scale of a portfolio will require an extensive governance organisation. This may involve, for example, committees with the responsibility for investment decisions or management of change.

What a Project Sponsor Does In Each Phase

While sometimes a project sponsor is clearly engaged from the start and other times they are nowhere to be seen, the best project sponsor is fully engaged with every phase of the project.

Initiation Duties

Project sponsors are instrumental in selecting the project manager during the initiation phase, and then they give that project manager a clear mandate, context for the project and set the level of their authority.

Also, during the project initiation, the project sponsor makes sure the project is appropriate for the organization, offering input on the project charter and participates in the kick-off meeting. The sponsor helps with the decision making during this phase.

Planning Duties

For the planning phase, the project sponsor is checking to make sure the project plan is realistic and feasible. This accounts for time restrictions and whether or not the team is tasked with expectations they cannot meet.

The project sponsor can help resolve issues, too, if they’re beyond the scope of the project manager. If there are other projects in play, the project sponsor is making sure they’re all working together and not against each other.

Implementation Duties

For the implementation and control phases, the project sponsor should work with the project manager, but not overstep boundaries. The project sponsor evaluates the project’s actual progress against what was planned and provides feedback to the project manager as necessary.

Sponsors also help the project manager and team work more autonomously to solve issues as they arise, while making sure that processes are being followed. They identify underlying factors that might cause problems and celebrate completion of milestones.

Closing Duties

During the closing phase, the project sponsor is part of the post-mortem evaluation on performance and other aspects of the project. They make sure that handoffs and signoffs are done properly. Project sponsors help facilitate the discussion that decides whether a project was a success or failure.

Overall, a project sponsor helps to streamline communications. They create trust and collaboration and keep problems from escalating. In terms of issues, they set up the instrument to identify problems with schedule, cost and quality. In that sense, they’re also in charge of making sure risk management is successful. Finally, they also encourage record-keeping for historical data storage.

Innovation Case Study: Test Automation & Ambit Enterprise Upgrade

A business case of how technology innovation successfully integrated into the business operations an improved the way of working that supported business success.

  
Areas of Science and TechnologyData Engineering, Computer Science
R&D Start DateDec 2018
R&D End DateSeptember 2019
Competent ProfessionalRenier Botha

 

Overview and Available Baseline Technologies

Within the scope of the project, the competent professionals sought to develop a regression testing framework aimed at testing the work carried out to upgrade the Ambit application[1] from a client service solution to a software as a service solution (SaaS) operating in the Cloud. The test framework developed is now used to define and support any testing initiatives across the Bank. The team also sought to automate the process, however this failed due to lack of existing infrastructure in the Bank. 

Initial attempts to achieve this by way of third-party solution providers, such as Qualitest, were unsuccessful, as these providers were unable to develop a framework or methodology which could be documented and reused across different projects. For this the team sought to develop the framework from the ground up. The project was successfully completed in September 2019. 

Technological Advances

The upgrade would enable access to the system via the internet, meaning users would no longer need a Cisco connection onto the specific servers to engage with the application. The upgrade would also enable the system to be accessed from devices other than a PC or laptop. Business Finance at Shawbrook is comprised of 14 different business units, with each unit having a different product which is captured and processed through Ambit. All the existing functionality, and business specific configuration needed to be transferred into the new Enterprise platform, as well as the migration of all the associated data. The competent professionals at Shawbrook sought to appreciably improve the current application through the following technological advances:

  • Development of an Automated Test Framework which could be used across different projects

Comprehensive, well executed testing is essential for mitigating risks to deployment. Shawbrook did not have a documented, standardised, and proven methodology that could be adopted by different projects to ensure that proper testing practises are incorporated into project delivery. There was a requirement to develop a test framework to plan, manage, govern and support testing across the agreed phases, using tools and practices that help mitigate risks in a cost-effective and commensurate way.

The test team sought to develop a continuous delivery framework, which could be used across all units within Business Finance. The Ambit Enterprise Upgrade was the first project at Shawbrook to adopt this framework, which lead to the development of a regression test pack and the subsequent successful delivery of the Ambit upgrade. The Ambit Enterprise project was the first project within the Bank which was delivered with no issues raised post release.

The development of a regression test pack which would enable automated testing of future changes or upgrades to the Ambit platform

Regression testing is a fundamental part of the software development lifecycle. With the increased popularity of the Agile development methodology, regression testing has taken on added importance. The team at Shawbrook sought to adopt an iterative, Agile approach to software development. 

A manual regression test pack was developed which could be used for future testing without the need for the involvement of business users. This was delivered over three test cycles with the team using the results of each cycle (bugs identified and resolved) to issue new releases. 

173 user paths were captured in the regression test pack, across 14 different divisions within Business Finance. 251 issues were found during testing, with some being within the Ambit application. Identifying and resolving these issues resulted in the advancement of Ambit Enterprise platform itself. This regression test pack can now be used for future changes to the Ambit Enterprise application, as well as future FIS[2] releases, change requests and enhancements, without being dependent on the business users to undertake UAT. The competent professionals at Shawbrook are currently using the regression test pack to test the integration functionality of the Ambit Enterprise platform.

  • Development of a costing tool to generate cost estimates for cloud test environment requirements

In order to resolve issues, solutions need to be tested within test environments. A lack of supply was identified within Shawbrook and there was an initiative to increase supply using the Azure cloud environment. The objective was to increase the capability within Business Finance to manage an Azure flexible hosting environment where necessary test environments could be set up on demand. There was also a requirement to plan and justify the expense of test environment management. The competent professionals sought to develop a costing tool, based on the Azure costing model, which could be used by project managers within Business Application Support (“BAS”) to quickly generate what the environment cost would be on a per day or per hour running basis. Costs were calculated based on the environment specification required and number of running hours required. Environment specification was classified as either “high”, “medium” or “low”. For example, the test environment specification required for a web server is low, an application server is medium while a database server is high. Shawbrook gained knowledge and increase its capability of the use of the Azure cloud environment and as a result are actively using the platform to undertake cloud-based testing.

The above constitutes an advance in knowledge and capability in the field of Data Engineering and Computer Science, as per sections 9 a) and c) of the BEIS Guidelines.

Technological Uncertainties and activities carried out to address them

The following technological uncertainties were encountered while developing the Ambit Enterprise upgrade, mainly pertaining to system uncertainty:

  • Implementation of the new Ambit Enterprise application could disrupt existing business processes

The biggest risks for the programme of change, was the potential disruption of existing business processes due to the implementation of the change without validation of the upgraded application against the existing functionality. This was the primary focus of the risk mitigation process for the project. Following the test phases set out in the test framework would enable a clear understanding of all the residual risks encountered approaching implementation, providing stakeholders with the context required to make a calculated judgement on these risks.

When an issue was identified through testing, a triage process was undertaken to categorise the issues as either a technical issue, or a user issue. User issues were further classified as “training” or “change of business process”. Technical issues were classified as “showstoppers”, “high”, “medium” and “low”. These were further categorised by priority as “must haves” and “won’t haves” in order to get well-defined acceptance criteria for the substantial list of bugs that arose from the testing cycles. In total, 251 technical issues were identified.

The acceptance criteria for the resolution of issues were:

  • A code fix was implemented
    • A business approved work around was implemented
    • The business accepted the risk

All showstoppers were resolved with either a code fix or and an acceptable work around. Configuration issues were within the remit of Shawbrook’s business application support (“BAS”) team to resolve, whilst other issues could only be resolved by the FIS development team. When the application went live, there were no issues raised post release, and all issues present were known and met the acceptance criteria of the business. 

  • Business processes may no longer align with the new web-based application

Since the project was an upgrade, there was the potential for operational impact of existing functionality due to differences between the Ambit client server solution, and the upgraded Ambit Enterprise web-based solution. The BAS team at Shawbrook were required to make changes to the business processes in order to align with the way the Ambit Enterprise solution now operated. Where Shawbrook specific issues could not be resolved through the configuration of the application with the business processes, changes were made to the functionality within Ambit, for example, additional plug-ins were developed for the Sales Portal platform to integrate with the Ambit Enterprise application. 

Because Ambit Enterprise was a web-based application, application and security vulnerabilities needed to be identified so that the correct security level was achieved. Because of this, performance and security testing, which was currently not being executed, needed to be introduced to the test framework. Performance testing also needed to be executed so that speed and stability requirements under the expected workloads were met.

Summary and Conclusions

The team at Shawbrook successfully developed a test framework which could be used across all projects within Business Finance. The development of the test framework lead to the generation of a regression test pack for the Ambit Enterprise upgrade. By undertaking these R&D activities, Shawbrook gained knowledge in the use of Azure Cloud Environment for testing, and increased its automated testing capabilities, enabling the transition to a continuous delivery framework whereby the majority of testing is automated.


[1] Ambit is the asset finance application operating within the business unit, 70-80 percent of transactions on all lending is captured and managed through Ambit

[2] FIS is the Ambit Enterprise vendor

Project Retrospective

These meetings go by many names – lessons learned, postmortems, retrospectives, after-action reviews, wrap-ups, project “success” meetings. Regardless of what you call them, they all have the same goal and follow the same basic pattern.

Retrospective – looking back on or dealing with past events or situations oran exhibition or compilation showing the development of work over a period of time.

An Agile retrospective is a meeting that’s held at the end of an iteration (sprint) in an agile project. During the retrospective, the team reflects on what happened in the iteration (sprint) and identifies actions for improvement going forward.

The Project Retrospective dedicates time to reviewing a completed project and learning from both the successes and the failures so the team and organisation can improve how they work going forward.

The general purpose is to allow the team, as a group, to evaluate its past working cycle. In addition, it’s an important moment to gather feedback on what went well and what did not.

Classic questions answered in these meetings:

  • What did we set out to do?
  • What actually happened?
  • Why did it happen?
  • What are we going to do next time?

 

“We do not learn from experience … we learn from reflecting on experience.”; John Dewey

Retrospectives give a team time to reflect on what they learned.

 

The Process

The process for debriefing a project covers roughly the same topics as the quick after-action discussion.

  1. Review the Project
  2. What went well and did not
  3. How can we do it better next-time

Review the project

Start by reviewing the project facts: goals, timeline, budget, major events, and success metrics.

In order to come up with useful ideas that everyone can agree on, the team needs a shared understanding of the facts and insight into the parts of the project in which they may not have been involved.

It’s important not to skip or rush through this step, especially for larger projects. People will arrive at the retrospective ready to discuss and solve problems, often assuming they know everything they need to know about what happened. This is rarely true.

If you are reviewing a project as a team, that means it took many people with unique experiences to get to that point. This step ensures everyone gets all the facts straight before they try to solve problems they may only partially understand.

What went well and what did not

This is the heart of the meeting. Everyone shares what they learned during the project: both the good and the bad.

In my opinion, this is the most fun and most challenging part of the meeting. As the meeting leader, you have an enormous impact on the success of your retrospective by deciding which questions you’ll ask and how the team shares their answers.

How can we do it better next-time

Real change is the ultimate measure of a retrospective’s success. To ensure that your retrospective results in something actually getting better, you’ll end the meeting by creating a specific action plan for improvements.