Blog

Agile Fixed Price Projects

Leave a comment

The Agile fixed price is a contractual model agreed upon by suppliers and customers of IT projects that develop software using Agile methods. The model introduces an initial concept & scoping phase after which budget, due date, and the way of steering the scope within the framework is agreed upon. This differs from traditional fixed-price contracts in that fixed-price contracts usually require a detailed and exact description of the subject matter of the contract in advance.

Fixed price contracts are evil – this is what can often be heard from agilest. On the other hand, those contracts are reality which many agile teams have to face. But what if we try to embrace and manage it instead of fighting against it? How can a company execute this kind of contract using agile practices to achieve better results with lower risk? This article will try to answer those questions.

Fixed Price, Time and Scope

Fixed price contracts freeze three project factors at once – money, time and scope – but this should not be a problem for agile teams. In fact, time boxing is common agile practice. Limiting money simply makes time boxing work better.

A real problem with fixed price contracts is the scope, which is fixed in terms of what should exactly be built instead of how much should we build.

Why are clients so obsessed with fixing the scope? We understand that they want to know how much they will pay (who does not want to know that) and when they will get the product. The only thing they don’t know, even if they will not always admit it, is what exactly they want as the final product.

The reason for fixing the scope has its roots in:

  • Lack of trust between the contractors.
  • Lack of understanding about how the agile software development methodology and processes work.
  • Misunderstanding what the scope means.

Every fixed price contract has a companion document, the “Requirements Specification” or something similar. Most of the time, working in an Agile way, the business requirements are relatively light weight criptic notes captured on stickies or story boards and not in comprehensive Business Requirement Documents (BRDs) pre-approved by business before developemnt commences. Documented requirements tries to reduce the risk of forgetting something important and tries to set a common understanding of what should be done to provide an illusion of predictability of what the business actually wants and needs in the final product.

Key wrong assumptions in fixing the scope are:

  • The more detail we include in the requirements and scope definition up front, the better we understand each other.
  • Well-defined scope will prevent changes.
  • A fixed scope is needed to better estimate price and time.

Converting the Fixed Scope into Fixed Budget

In understanding that the main conflict between application of an agile mindset and a fixed price contract lies in the fixed scope, we can now focus on converting the fixed scope into the fixed budget.

A well defined scope is done by capturing business requirements in as many user stories instead of providing a detailed specification of requirements. These stories are built into a product backlog. The effort required to deliver each story is estimated using one of many story point techniques, like planning poker.

It is key to understand that a higher level of detail in software requirements specifications, means two completely different things for both parties within a contract. Software companies (vendors / supplier), responsible for developing applications, will usually focus on technical details while the company using the software (buying party / customer) is more user focussed and business outcome oriented.

In compiling specifications four key aspects are in play:

  • User stories is a way of expressing requirements, understandable for both suppliers and customers. The understanding builds trust and a sense of common vision. User stories are quick to write and quick to destroy, especially written on an index card. They are also feature oriented, so they can provide a good view on the real scope of a project, and we can compare them with each other in terms of size or effort.
  • Acceptance Ctiteria, captured for each user story, are a formalised list of requirements that ensires a user story is completed with all scenarios taken into account – it specifies the conditions under which a story is fulfilled.
  • Story points as a way of estimating stories, are units of measure for expressing an estimate of the overall effort required to fully implement a user story or other pieces of work on the product backlog. The team will access the effort to deliver a story against the acceptance criteria and in relation to other stories. Various proven estimation techniques can be adopted by the team for example effort can be expressed as a T-shirt size (i.e. Large, Medium, Small). To quantify the effort, each T-shirt size can be assigned a number of story points i.e. Large = 15 storypoints, Medium 5 storypoints and Small = 2 story points. (See also the section on Estimation below). The intention of using story points, instead of man hours, is to lower the risk of underestimating the scope because, story points in their nature are relative and focused on the whole scope or on a group of stories, while traditional estimation (usually done in man-hours) tries to analyse each product feature in isolation.
  • Definition of done is another way of building trust and common understanding about the process and all the future plans for the project. It’s usually the first time clients see user stories and while they may like the way the stories are written, it may not be so obvious what it means to implement a story. Development teams who confirm with the client their definition of done, in conjunction with the acceptance criteria with, illustrate that they know better what the client’s expectations are.Development on a story will be completed when the defenition of done is achieved. This supports better estimation. In addition on the client side, the definition of done, in conjunction with the accpetance criteria, sets the criteria for user story acceptance.

Using the above four aspects, will provide the building blocks to define the scope budget in story points. This story point budget and not the stories behind it, is the first thing that should be fixed in the contract.

This sets the stage for change.

While we have the scope budget fixed (in terms of story points) we still want to embrace change, the agile way. As we are progressing with the project delivery, and especially during backlog refinement, we have the tools (user stories and points) which we can use to compare one requirement with another. This allows us to refine stories and change requirements along the way within a defined story point budget limit. And if we can stay within that limit, we can also stay within the fixed price and time.

Before Estimation

The hardest part in preparing a fixed price contract is to define the price and schedule that will be fixed based on, in most cases, not so well-defined requirements but preferably a well defined scope.

How can you prepare the project team (customer & supplier) to provide the best possible initial estimation?

Educate: Meet with your client and describe the way you’re going to work. We need to tell what the stories are all about, how we are going to estimate them and what is the definition of done. We might even need to do that earlier, when preparing an offer for the client’s Request For Proposal (RFP). Explain the agile delivery mothodology and you will use it to derive the proposal.

Capture user stories: This can be arranged as a time-boxed sessions, usually not taking no more than 1 or 2 days. This is long enough to find most of the stories forming the product vision without falling into feature creep. At this point it is also very important to discuss the definition of done, acceptance criteria for stories, iterations and releases with the client.

We need to know:

  • The environment in which stories should be tested (like the number of browsers or mobile platforms, or operating systems)
  • What kind of documentation is required
  • Where should finished stories be deployed so that the client can take a look at them
  • What should the client do (i.e. take part in a demo session)
  • How often do we meet and who participates
  • etc.

This and probably many more project specific factors will affect the estimation and will set a common understanding about the expectations and quality on both sides. They will also make the estimation less optimistic as it often happens when only the technical aspects of story implementation are considered by the team.

Estimation

Having discussed with the client a set of stories and a definition of done, we can now start the estimation. This is a quite well-known part of the process. The most important activity here is to engage as many future team members as possible so that the estimation is done collectively. Techniques like planning poker are known to lower the risk of underestimation because of some particular team member’s point of view, especially if this team member is also the most experienced-one, which is usually the case when estimations are done be one person. It is also important that the stories are estimated by the people who will actually implement the system.

Apart from T-shirt sizes to expressed effort estiamtion, as mentioned under Story Points above, the Fibonacci-like scale (1, 2, 3, 5, 8, 13, 20, 40, 100) comes in handy for estimating stories in points. Relative estimation starts with finding a set of easiest or smallest stories. They will get 1 or 2 points as a base level for further estimation.

In fact during the initial estimation it is often hard to estimate stories using the lowest values like 1 or 2. The point is, the higher the estimation, the less we know about the story. This is also why estimating in points is easier at this early stage, because it is far easier to tell that a story A is 2x as complicated as story B than to tell that story A will take 25 man-hours to get it Done (remember the definition of done?) and the story B will take 54 hours.

This works well even if we choose 3 or 5 point stories as the base level and if we do that, then it will be easier to break them down into smaller stories later during the development phase. Beware however the stories of 20, 40 or 100 points. This kind of estimation suggests that we know nothing about what is to be implemented, so it should be discussed with the client here and now in a little more detail instead of just happily putting it in the contract.

The result of the estimation is a total number of story points describing the initial scope for a product to be built. This is the number that should be fixed in terms of scope for the contract, not the particular stories themselves.

Deriving the Price and Time

Total number of points estimated based on the initial set of stories does not give us the price and time directly. To translate story points into commercial monetory numbers we need to know more about the development team’s makeup described in the number of differently skilled resources within a team, and the team’s ability to delivery work which is expresessed in an agile KPI referred to as the Team Capacity and/or Velocity.

The team’s velocity refers to the pace, expressed in story points per development cycle or sprint, at which a team can deliver work. The team’s capacity is defined by the average number of story points the team can deliver within a development cycle or sprint. An increase in the velocity, as a result of increased efficiency and higher productivity, will over time increase the teams capacity. Understandably, changing the makeup of the team will impact the team’s velocity/capacity. The team’s capacity and velocity is established through experience on previous projects the team delivered. A mature agile team is characterised by a stable and predictable velocity/capacity.

Let’s use a simple example to demonstrate how the team makeup and velocity are used to determine the project cost and time.

Assume we have:

  • Estimated our stories for a total of 300 story points.
  • The team makeup consists of 5 resources – 3 developers, 1 tester and a team leader.
  • Agile Scrum will be team’s delivery methodology.
  • Experience has shown this teams capacity / velocity is 30 story points over development cycle or sprint length of 2 weeks.

Determine the predicted Timeline

Time = <Points> / <Velocity> * <Sprint length>

Thus…

Time = 300 / 30 * 2 = 20 weeks (or 10 sprints)

Many factors during the project may affect the velocity, however if the team we’re working with is not new, and the project we’re doing is not a great unknown for us, then this number might be actually given based on some evidence and observations of the past.

Now we may be facing one of the two constraints that the client could want to impose on us in the contract:

  • The client wants the software as fast as we can do it (and preferably even faster)
  • The client wants as much as we can do by the date X (which is our business deadline)

If the calculated time is not acceptable then the only factor we can change is the team’s velocity. To do that we need to change the teams makeup and extend the team, however this is not working in a linear way i.e. doubling the team size will nor necessarily double its velocity but it should increase the velocity as the team should be able to do more work within a development cycle.

Determine the predicted Price

Calculating the price is based on the makeup of the team and the assocaited resource/skill set rate card (cost per hour).

The teams cost per sprint is calculated by the % of time or number of hours each reasurce will spend on the project within a sprint.

For our eaxmple, let assume:

  • A Sprint duration of 2 weeks has 10 working days and working 8 hours per day = 80h per sprint.
  • Developer 1 will work 100% on the project at a rate of £100 per hour.
  • Developer 2 will work 50% of his time on the project at a rate of £80 per hour.
  • Developer 3 will also work 100% on the project at a rate of £110 per hour.
  • The Team Leader will work 100% on the project at a rate of £150 per hour.
  • The Tester will be 100% on the project at £80 per hour.

The team cost per sprint (cps) will thus be…

Resource cost per sprint (cps) = <hours of resource per sprint> * <resource rate per hour>

  • Developer 1 cps = 80h * £100 = £8,000
  • Developer 2 cps = 40h (50% of 80h) * £80 = £3,200
  • Developer 3 cps = 80h * £110 = £8,800
  • Team Leader cps = 80h * £150 = £12,000
  • Tester cps = 80h * £80 = £6,400

Total team cost per sprint = (sum of the above) = £38,400 per sprint

Project predicted Price = <Number of sprints (from Predicted Timeline calculation)> * <Team cost per sprint>

Project predicted Price = 10 sprint * £38,400 per sprint = £384,000

So the Fix Price Contract Values are:

  • Price: £576,000
  • Time: 20 weeks (10 x 2 week sprints)
  • Scope: 300 Story Points

These simplistic calculations are of course just a part of the cost that will eventually get into the contract, but they are also the part that usually is the hardest to define. The way in which these cost are calculated also shows how delivering agile projects can be transferred into the contract negotiations environment.

Negotiating on Price

“So why is it so expensive?”, most customers ask.

This is where negotiations actually start.

The only factor a software company is able to change is its man-hour cost rate. It is the rate card that we are negotiating. Not the length of our iteration, not even the number of iterations. Developers, beyond popular believe, has no superhero powers and will not start working twice as fast just because it is negotiated this way. If we say we can be cheaper it is because we will earn less not because we will work faster.

The other factor that can influence the price is controlled by the customer – the scope.

Tracking Progress and Budget

Now that we have our contract signed, it is time to actually build the software within the agreed constraints of time and budget.

Delivering your fixed price project in an agile way is not a magic wand that will make all your problems disappear but it if measured correctly it will give you early visisbility. That is where the project metrics and more specific the burndown graphs come in to play. Early visibility provides you with the luxury of early corrective action ensuuring small problems do not turn into large expesive one’s.

One such a small mistake might be the team velocity used when the project price was calculated. Burndown charts are a very common way of tracking progress in many agile projects. It shows the predicted/forecasted completion of work rate (velocity) against the actual velocity to determine if the project is on track.

Figure 1 – Planned scope burndown vs. real progress.

They are good to visualize planned progress versus the reality. For example the burndown chart from Figure 1 looks quite good:

We are a little above the planned trend but it does not mean that we made a huge mistake when determining our velocity during the contract negotiations. Probably many teams would like their own chart to look like this. But the problem is that this chart shows only two out of three contract factors – scope ( presented as a percentage of story points) and time (sprints). So what about money?

Figure 2 – Scope burndown vs budget burndown.

The chart on Figure 2 shows two burndowns – scope and budget. Those two trends are expressed here as percentages for the purpose. There is no other way to compare those two quantities calculated (one in story points and the other in man-hours or money spent).

To track the scope and budget this way we need to:

  • Track the story points completed (done) in each iteration.
  • Track the real time spent (in man-hours) in each iteration.
  • Recalculate the total points in your project into 100% of our scope and draw a burndown based on percentage of the total scope.
  • Recalculate the budget fixed in the contract (or its part) into a total available man-hours – this is our 100% of a budget – and draw a budget burndown based on percentage of the total budget usedto date.

The second chart does not look promising. We are spending more money to stay on track than we expected. This is probably because of using some extra resources to actually achieve the expected team’s velocity. So having all three factors on one chart makes problems visible and iteration (sprint) 4 in this example is where we start to talk with the client and agree on mitigating actions, before it is too late.

Embracing Change

Agile embraces change, and what we want to do is to streamline change management within the fixed price contract. This has always been the hard part and it still is, but with a little help through changing the focus from the requirements analysis into some boundary limits early in the process, we want to welcome change at any stage of the project.

Remember earlier in the process changed fixed scope into fixed budget. The 300 story points from the example allows us to exchange the contents of the initial user story list without changing the number of story points. This is one of the most important aspects that we want to achieve with a fixed price contract done the agile way.

The difficulty here is to convince the client that stories can be exchanged because they should be comparable in the terms of effort required to complete them. So if at any point client has a new great idea that we can express as some new set of stories (worth for example 20 points) then it is again up to the client if we are going to remove stories worth 20 points from the end of our initial backlog to make a place for the new ones.

Or maybe the client wants to add another iteration (remember the velocity of 20 points per iteration?). It is quite easy to calculate the price of introducing those new stories, as we have already calculated the cost of a sprint.

What still is the most difficult in this kind of contracts is when we find out during the project that some stories will take longer than expected because they were estimated as epics and now we know more about them than we did at the beginning. But still this might not always be the case, because at the same time some stories will actually take less. So again tracking during the contract execution will provide valuable information. Talking about the problems earlier helps negotiating as we can talk about actions that need to be taken to prevent them instead of talking about the rescue plans after the huge and irreversible disaster.

Earning Mutual Trust

All the techniques discussed, require one thing to be actually used succesfully with a fixed price contract and that is – trust. But as we know, trust is not earned by describing but by actually doing. Use the Agile principles to demonstrate the doing, to show the progress and point out the problems early.

With every iteration we want to build value for the client. But what is more important, we focus on delivering the most valuable features first. So, the best way to build the trust of a client might be to divide the contract.

Start small, with some pilot development of 2 or 3 iterations (which will also be fixed price, but shorter). The software delivered must bring an expected value to the client. In fact it must contain some working parts of the key functionalities. The working software proves that you can build the rest. It also gives you the opportunity to verify the first assumptions about the velocity and eventually renegotiate the next part.

The time spent on the pilot development, should also be relatively small when compared to the scope left to be done. This way if our clients are not satisfied with the results, they can go away before it is too late and they no longer need to continue the contract and eventually fail the project.

Summary

Fixed price contracts are often considered very harmful and many agile adopters say that we should simply avoid them. But most of the time and as long as customers request them, they cannot be avoided, so we need to find ways to make them work for the goal, which is building quality software that can demonstrably increase business value propositions and competitive advantage.

I believe that some aspects of a fixed rpice agile contract are even Good and healthy for agile teams, as it touches on the familiar while instilling commercial awareness. Development teams are used to working with delivery targets and business deadlines. That is exactly what the fixed date and price in the contract are – healthy time boxes and boundaries keeping us commercially aware and relevant.

Keep the focus on scope and you can still deliver your agile project within a fixed time and budget.

The intention of this article was not to suggest that agile is some ultimate remedy for solving the problem of fixed price contracts but to show that there are ways to work in this context the agile way.

Advertisement

What makes a good Technical Specification Document

Leave a comment

Writing a technical spec increases the chances of having a successful project, service, or feature that all stakeholders involved are satisfied with. It decreases the chances of something going horribly wrong during implementation and even after you’ve launched your product. 

As a software engineer, your primary role is to solve technical problems. Your first impulse may be to immediately jump straight into writing code. But that can be a terrible idea if you haven’t thought through your solution. 

You can think through difficult technical problems by writing a technical spec. Writing one can be frustrating if you feel like you’re not a good writer. You may even think that it’s an unnecessary chore. But writing a technical spec increases the chances of having a successful project, service, or feature that all stakeholders involved are satisfied with. It decreases the chances of something going horribly wrong during implementation and even after you’ve launched your product. 

Developing software solutions using the Agile delivery methodology, your technical specification document is a living document that will be continuously updated as you progressing through the development sprints and the specifics solution designs and associate technical specifications aspects are being confirmed. Initially the tech spec will be describing he the solution at a high level, making sure all requirements are addressed within the solution. As requirements changes through the delivery life-cycle or as the technical solution evolves to working acceptance, the technical specifications are updated accordingly. Every agile story describing a functional piece, will cover requirements, acceptance criteria, solution architecture and technical specification. All the specs are included in the evolving technical specification. At the end of a development project the technical specifications are a good reference point for ongoing improvement development and support.

What is a technical specification document?

A technical specification document outlines how you’re going to address a technical problem by designing and building a solution for it. It’s sometimes also referred to as a technical design document, a software design document, or an engineering design document. It’s often written by the engineer who will build the solution or be the point person during implementation, but for larger projects, it can be written by technical leads, project leads, or senior engineers. These documents show the engineer’s team and other stakeholders what the design, work involved, impact, and timeline of a feature, project, program, or service will be. 

Why is writing a technical spec important?

Technical specs have immense benefits to everyone involved in a project: the engineers who write them, the teams that use them, even the projects that are designed off of them. Here are some reasons why you should write one. 

Benefits to engineers

By writing a technical spec, engineers are forced to examine a problem before going straight into code, where they may overlook some aspect of the solution. When you break down, organize, and time box all the work you’ll have to do during the implementation, you get a better view of the scope of the solution. Technical specs, because they are a thorough view of the proposed solution, they also serve as documentation for the project, both for the implementation phase and after, to communicate your accomplishments on the project. 

With this well-thought out solution, your technical spec saves you from repeatedly explaining your design to multiple teammates and stakeholders. But nobody’s perfect;  your peers and more seasoned engineers may show you new things from them about design, new technologies, engineering practices, alternative solutions, etc. that you may not have come across or thought of before. They may catch exceptional cases of the solution that you may have neglected, reducing your liability. The more eyes you have on your spec, the better. 

Benefits to a team

A technical spec is a straightforward and efficient way to communicate project design ideas between a team and other stakeholders. The whole team can  collaboratively solve a problem and create a solution. As more teammates and stakeholders contribute to a spec, it makes them more invested in the project and encourages them to take ownership and responsibility for it. With everyone on the same page, it limits complications that may arise from overlapping work. Newer teammates unfamiliar with the project can onboard themselves and contribute to the implementation earlier.  

Benefits to a project

Investing in a technical spec ultimately results in a superior product.  Since the team is aligned and in agreement on what needs to be done through the spec, big projects can progress faster. A spec is essential in managing complexity and preventing scope and feature creep by setting project limits. It sets priorities thereby making sure that only the most impactful and urgent parts of a project go out first. 

Post implementation, it helps resolve problems that cropped up within the project, as well as provide insight in retrospectives and postmortems. The best planned specs serve as a great guide for measuring success and return on investment of engineering time. 

What to do before writing a technical spec

Gather the existing information in the problem domain before getting started. Read over any product/feature requirements that the product team has produced, as well as technical requirements/standards associated with the project. With this knowledge of the problem history, try to state the problem in detail and brainstorm all kinds of solutions you may think might resolve it. Pick the most reasonable solution out of all the options you have come up with. 

Remember that you aren’t alone in this task. Ask an experienced engineer who’s knowledgeable on the problem to be your sounding board. Invite them to a meeting and explain the problem and the solution you picked. Lay out your ideas and thought process and try to persuade them that your solution is the most appropriate. Gather their feedback and ask them to be a reviewer for your technical spec.

Finally, it’s time to actually write the spec. Block off time in your calendar to write the first draft of the technical spec. Usea collaborative document editor that your whole team has access to. Get a technical spec template (see below) and write a rough draft. 

Contents of a technical spec

There are a wide range of problems being solved by a vast number of companies today. Each organization is distinct and creates its own unique engineering culture. As a result, technical specs may not be standard even within companies, divisions, teams, and even among engineers on the same team. Every solution has different needs and you should tailor your technical spec based on the project. You do not need to include all the sections mentioned below. Select the sections that work for your design and forego the rest.

From my experience, there are seven essential parts of a technical spec: front matter, introduction, solutions, further considerations, success evaluation, work, deliberation, and end matter. 

1. Cover Page

  • Title 
  • Author(s)
  • Team
  • Reviewer(s)
  • Created on
  • Last updated
  • Epic, ticket, issue, or task tracker reference link

2. Introduction

2.1 Overview, Problem Description, Summary, or Abstract

  • Summary of the problem (from the perspective of the user), the context, suggested solution, and the stakeholders. 

2.2 Glossary  or Terminology

  • New terms you come across as you research your design or terms you may suspect your readers/stakeholders not to know.  

2.3 Context or Background

  • Reasons why the problem is worth solving
  • Origin of the problem
  • How the problem affects users and company goals
  • Past efforts made to solve the solution and why they were not effective
  • How the product relates to team goals, OKRs
  • How the solution fits into the overall product roadmap and strategy
  • How the solution fits into the technical strategy

2.4 Goals or Product and Technical Requirements

  • Product requirements in the form of user stories 
  • Technical requirements

 2.5 Non-Goals or Out of Scope

  • Product and technical requirements that will be disregarded

2.6 Future Goals

  • Product and technical requirements slated for a future time

2.7 Assumptions

  • Conditions and resources that need to be present and accessible for the solution to work as described. 

3. Solutions

3.1 Current or Existing Solution Design

  • Current solution description
  • Pros and cons of the current solution

3.2 Suggested or Proposed Solution Design 

  • External components that the solution will interact with and that it will alter
  • Dependencies of the current solution
  • Pros and cons of the proposed  solution 
  • Data Model or Schema Changes
    • Schema definitions
    • New data models
    • Modified data models
    • Data validation methods
  • Business Logic
    • API changes
    • Pseudocode
    • Flowcharts
    • Error states
    • Failure scenarios
    • Conditions that lead to errors and failures
    • Limitations
  • Presentation Layer
    • User requirements
    • UX changes
    • UI changes
    • Wireframes with descriptions
    • Links to UI/UX designer’s work
    • Mobile concerns
    • Web concerns
    • UI states
    • Error handling
  • Other questions to answer
    • How will the solution scale?
    • What are the limitations of the solution?
    • How will it recover in the event of a failure?
    • How will it cope with future requirements?

3.3 Test Plan

  • Explanations of how the tests will make sure user requirements are met
  • Unit tests
  • Integrations tests
  • QA

3.4 Monitoring and Alerting Plan 

  • Logging plan and tools
  • Monitoring plan and tools
  • Metrics to be used to measure health
  • How to ensure observability
  • Alerting plan and tools

3.5 Release / Roll-out and Deployment Plan

  • Deployment architecture 
  • Deployment environments
  • Phased roll-out plan e.g. using feature flags
  • Plan outlining how to communicate changes to the users, for example, with release notes

3.6 Rollback Plan

  • Detailed and specific liabilities 
  • Plan to reduce liabilities
  • Plan describing how to prevent other components, services, and systems from being affected

3.7 Alternate Solutions / Designs

  • Short summary statement for each alternative solution
  • Pros and cons for each alternative
  • Reasons why each solution couldn’t work 
  • Ways in which alternatives were inferior to the proposed solution
  • Migration plan to next best alternative in case the proposed solution falls through

4. Further Considerations

4.1 Impact on other teams

  • How will this increase the work of other people?

4.2 Third-party services and platforms considerations

  • Is it really worth it compared to building the service in-house?
  • What are some of the security and privacy concerns associated with the services/platforms?
  • How much will it cost?
  • How will it scale?
  • What possible future issues are anticipated? 

4.3 Cost analysis

  • What is the cost to run the solution per day?
  • What does it cost to roll it out? 

4.4 Security considerations

  • What are the potential threats?
  • How will they be mitigated?
  • How will the solution affect the security of other components, services, and systems?

4.5 Privacy considerations

  • Does the solution follow local laws and legal policies on data privacy?
  • How does the solution protect users’ data privacy?
  • What are some of the tradeoffs between personalization and privacy in the solution? 

4.6 Regional considerations

  • What is the impact of internationalization and localization on the solution?
  • What are the latency issues?
  • What are the legal concerns?
  • What is the state of service availability?
  • How will data transfer across regions be achieved and what are the concerns here? 

4.7 Accessibility considerations

  • How accessible is the solution?
  • What tools will you use to evaluate its accessibility? 

4.8 Operational considerations

  • Does this solution cause adverse aftereffects?
  • How will data be recovered in case of failure?
  • How will the solution recover in case of a failure?
  • How will operational costs be kept low while delivering increased value to the users? 

4.9 Risks

  • What risks are being undertaken with this solution?
  • Are there risks that once taken can’t be walked back?
  • What is the cost-benefit analysis of taking these risks? 

4.10 Support considerations

  • How will the support team get across information to users about common issues they may face while interacting with the changes?
  • How will we ensure that the users are satisfied with the solution and can interact with it with minimal support?
  • Who is responsible for the maintenance of the solution?
  • How will knowledge transfer be accomplished if the project owner is unavailable? 

5. Success Factors

5.1 Impact

  • Security impact
  • Performance impact
  • Cost impact
  • Impact on other components and services

5.2 Metrics

  • How will you measure success?
  • List of metrics to capture
  • Tools to capture and measure metrics

6. Work Execution

6.1 Work estimates and timelines

  • List of specific, measurable, and time-bound tasks
  • Resources needed to finish each task
  • Time estimates for how long each task needs to be completed

6.2 Prioritization

  • Categorization of tasks by urgency and impact

6.3 Milestones

  • Dated checkpoints when significant chunks of work will have been completed
  • Metrics to indicate the passing of the milestone

6.4 Future work

  • List of tasks that will be completed in the future

7. Deliberation

7.1 Points under Discussion or Dispute

  • Elements of the solution that members of the team do not agree on and need to be debated further to reach a consensus.

b. Open Questions and Issues

  • Questions about matters and issues you do not know the answers to or are unsure that you pose to the team and stakeholders for their input. These may include aspects of the problem you don’t know how to resolve yet. 

8. Relating Matters, References & Acknowledgements

8.1 Related Work

  • Any work external to the proposed solution that is similar to it in some way and is worked on by different teams. It’s important to know this to enable knowledge sharing between such teams when faced with related problems. 

8.2 References

  • Links to documents and resources that you used when coming up with your design and wish to credit. 

8.3 Acknowledgments

  • Credit people who have contributed to the design that you wish to recognize.

After you’ve written your technical spec

Now that you have a spec written, it’s time to refine it. Go through your draft as if you were an independent reviewer. Ask yourself what parts of the design are unclear and you are uncertain about. Modify your draft to include these issues. Review the draft a second time as if you were tasked to implement the design just based on the technical spec alone. Make sure the spec is a clear enough implementation guideline that the team can work on if you are unavailable. If you have doubts about the solution and would like to test it out just to make sure it works, create a simple prototype to prove your concept. 

When you’ve thoroughly reviewed it, send the draft out to your team and the stakeholders. Address all comments, questions, and suggestions as soon as possible. Set deadlines to do this for every issue. Schedule meetings to talk through issues that the team is divided on or is having unusually lengthy discussions about on the document. If the team fails to agree on an issue even after having in-person meetings to hash them out, make the final call on it as the buck stops with you. Request engineers on different teams to review your spec so you can get an outsider’s perspective which will enhance how it comes across to stakeholders not part of the team. Update the document with any changes in the design, schedule, work estimates, scope, etc. even during implementation.

Conclusion

Writing test specs can be an impactful way to guarantee that your project will be successful. A little planning and a little forethought can make the actual implementation of a project a whole lot easier.  

lovingmydesk.com

Leave a comment

Hiya!

We are delighted to share our passion for travel and photography with you in a way that can make your day brighter and cheer those around you.

Grab some cool photos from our site, upload them into your video conferencing tool as virtual backgrounds and change them as often as every virtual meeting or even mid-meeting if the mood takes you.

Share the cheer, be inspirational, make them laugh and open the meeting with some all important personal chat, LovingMyDesk.com is the perfect video conference ice breaker and its free!

We have built this site to share the love, as an initial concept first so please click away download photos and use them on your computer, tablet or phone. If we see enough people having fun we may take it to the next stage, until then let us know what improvements you would like to see.

All we ask is you enjoy, share the goodness and perhaps leave us the odd comment if you like this idea whether we should take our super lean, hacked together start-up concept to the next stage?

So tell us what you think, like and share with others who might need a smile too.

Cheers

Renier and Stuart

#FreePictures #VirtualBackground #VideoConference

Be aware of scammers while using email…

Leave a comment

Many businesses have had to adapt to new working practices because of the coronavirus (COVID-19) situation. This has often meant an increase in emails and more frequent calls with suppliers, customers, banks and other organisations.
Scammers have been taking advantage of this. Cases are on the increase where fraudsters are calling businesses pretending to be from their phone or internet provider, their bank or even a retailer. They’ll ask for payments, or for staff to download software that then gives them control of that staff member’s device. Some have even taken control of genuine email addresses and used them to request payments, making it more difficult to spot the signs of a scam.
With this in mind, it’s now even more important to have strong, clear processes in place for keeping data safe.

Can you spot a scam?
Even if you know all the hallmarks and what to look out for, with ever-more sophisticated ways to access your data, scams are getting harder to spot. If a fraudster called or emailed you or a member of staff pretending to be a known supplier, would you know it was a scam?
They might even contact a staff member pretending to be you. For example, how can you tell if this email’s genuine?

Put checks and processes in place
To help you and your staff spot fraudulent attempts, here are some tips on the checks and processes you should have in place. Remember – it’s good to have a healthy level of suspicion.

  • If you get an email out of the blue that asks you to click on a link or attachment, don’t do it – even if the sender seems familiar – and even if it appears to be coming from a known email address. Instead, contact the apparent sender using different details that you already know and trust to verify the request.
  • When someone calls unexpectedly, don’t give them any information like personal details, bank details or pins.
  • Never download any software onto your device if you’re asked to – fraudsters can use this to access your personal information, even your bank account. Instead, call them back on a known number to check they’re genuine.
  • You can also search for a number to see if a listed number you’ve been asked to call is genuine. Have a payment-checking process in place. For example, if you receive a request to update the bank details you have on file or get new bank details for a payment, confirm this by calling that person or organisation using details you already have, and not those provided in the request. You should also do this with requests from anyone within your own organisation.
  • Have security policies in place, such as having strong passwords, using an encrypted VPN (virtual private network) when working from home, and using an extra layer of authentication for email and payment processes (such as a unique code texted to your mobile) – and test these processes often.
  • Make sure you and all your staff, regardless of their role, are made aware of the checks and processes regularly.

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

Leave a comment

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

What is Solution Design & Architecture:

Solution, Design 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 easily supported while scalable and powerful enough to deliver a feature rich solution that can be integrated into complex operational estates. 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. You can read more on choosing the right tech stack here.
  • Modular approach – using a service oriented architecture (SOA) model to ensure the solution can be functionally scaled, up and down to align with feature required, by using independently functioning modules of 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 enhancements and fault finding in case something goes wrong. It also makes the developed platform more agile to adapt to continuous business environment and market changes with less overall impact and system changes.
  • Customer data at the heart of a solution – Be clear on Master vs Slave customer and data records and ensure the needed integration between master and slave data within inter-connecting systems and platforms, with the needed security applied to ensure privacy and data integrity. Establish a Single Customer and Data Views (single version of the truth) from the design off-set. Ensure personal identifiable 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 modules and associated 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 – A tiered architecture ensure physical differentiation between user and customer facing interfaces, system logic and processing algorithms and the storage components of a solution. Various security precautions, guidelines and best practices should be imbedded within the software development by design. This should be articulated within the solution architecture, infrastructure and service software code. Penetration Testing and the associated platform hardening requirements should feed back into the solution architecture enhancement as required.
  • Identity Management – Single Sign On (SSO) user management and application roles to assign access to different modules, features and functionality to user groups and individuals.
  • Integration – data exchange, multi-channel user interface, compute and storage components of the platform, how the different components inter-connects through secure connection with each other, other applications and systems (API and gateway) within the business operations estate and to external systems.
  • 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, Automated 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, DevOps. Make sure non-functional Dev-Ops related requirements are covered in the same manner as
  • 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

Leave a comment

#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

1 Comment

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 Gartner RPA Magic Quadrant report …Download

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

Leave a comment

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

Leave a comment

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

Leave a comment

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