How to align your business vision with the technology rollout?

As a growing business, you may be facing these challenges:

• You need to scale fast because of investment and growth without losing the business vision.
• Delivery vs. management team is misaligned on business vision and goals and what can be achieved within the pressures.
• You need to deliver on the promises – keep track of the product development.
• You need to avoid poor definitions of software requirements to prevent the failure of software development projects.
• You need to have scheduling and planning based on correct estimations for the work ahead to fit into the deadlines.
• You need to ensure investors that you are on track with your business plan.
• You need to motivate the team and get them to add value to the bigger picture.
• You are wondering how to prevent the late discovery of requirements’ problems that would drive failed client delivery expectations as defects have not been planned.

If that is the case, there might be a solution for you! Keep reading our article where we outline the strategy to meet your business goals.

The big goals

Start-ups often embrace great ideas that need to be underpinned by solid technology and software solutions. The start-up technical team would embrace software development projects having high aspirations to achieve the end result fast. However, as software development projects materialize, the more complexity arises, the higher the frustrations when the development deflects.

Solid base with clear software requirements

Poor definition of software requirements leads to the failure of software development projects. Poor software definitions mean inadequate usage scenarios, lack of sufficient detail around the desired outcome, or completely not aligned with the business vision. Simply put, if you start off on the wrong foot, you are setting yourself up for failure. And this applies across the full spectrum of a software project – design, engineering, testing and project management.

Early discovery of problems with requirements

It would be too optimistic to say that all mistakes will be avoided. Even in cases where there is a strong delivery team, the problems with software requirements will come up and you may have to address these in the mid-term of the project. Why so?

• Architects and designers will see that something is missing when mapping the business requirements into the designs.
• UI/UX and content writers will spot inconsistencies between the business vision and the usage scenarios.
• Engineers will shout they need more details, and
• Project managers will not be able to obtain the anticipated work since the coherent units of work are not clear to everyone.

Nevertheless, such gaps can be addressed, but at the cost of project delays or cost overruns.

Late discovery of problems with requirements

Various studies show that technical issues contribute between 3% – 10% to why projects fail. What happens is that despite the perfect knowledge of technology or precise use of technical constructs for flawless non-functional behaviour of the system to be delivered, the end result does not do what it needs to. This results in defects and they originate from poor initial software requirements.

• Defects arising from lack of or ambiguity of requirements are discovered closer to production and will have a bigger negative impact. QA cannot catch them since the description is wrong and therefore testing is wrong.
• Defects take more time to fix it. 80% of the actual rework can be due to requirements defects and only 20% – to technical and environmental factors. Wrong requirements lead to wrong designs.
• Defects cannot be anticipated and therefore cannot be factored into a plan. Therefore, they will inevitably lead to failed expectations.

Accepting an ongoing change in requirements has its price

Requirements’ volatility and expected changes are typical in modern software projects– unlike hardware and construction, it is in the very nature of the software. They do come at a cost as it forces technical teams to create designs to accommodate various unexpected changes to the functional and non-functional requirements. This may create unnecessarily complex designs that cause an overhead in the future. Unless requirement changes are dedicated by disrupting conditions from the market, competition or conditions in the client organization, they should be minimized.

The Solution – Functional Blueprint

Drawing from years of experience, the biggest factor for not delivering value is the lack of alignment with the business goals. This is usually the result of the different decomposition of Why-What-How within the parties involved (the startup, the service delivery, and investors). The “What” is straightforward, therefore, the remaining two are easy to align; however, startups risk having a mechanism for effective management of the “What”.

Five Reasons to choose Functional Blueprint

Estafet’s Functional Blueprint steps on a special approach to requirements engineering to build the foundation of requirements excellence. The focus is on 5 different aspects which, addressed altogether, bring tangible improvement to business and functional fit:

1. The Domain knowledge

Nearshore companies are excellent in (particular) technology and fluent in managing projects in different engagement models. What they usually lack is an understanding of the client’s business domain.

Industry specialization does not fix that. Industry segment vertical specialization would be still too wide and not a fit for most innovative companies due to the distinctive traits and nuances they have in their business model.

“I hear you and I am listening carefully but I still don’t understand what you are saying” – a typical scenario caused by different levels of understanding of the business domain. External staff are provided explanations but, due to lack of fundamental knowledge, often shy away from asking questions and furthering their understanding. Usual behaviour is to silently accept that they will “deal with it later” expecting something magical to happen to address this gap later. This leads to “We need more details” – the dominant phrase of software engineers and quality assurance staff during the execution phase. “What details – it is all clear” – the typical answer from the requestor, stakeholder or business owner.

Estafet’s Functional Blueprint pays extra attention to obtaining knowledge of the business domain and of the specific nuances that the clients’ unique business model adds. This is a solid fundament for further success in requirements engineering, understanding common terminology, business processes, and typical use cases. All this brings the parties closer and maximizes the value from any further communications and exchanges related to requirements and scope.

2. Emphasis on requirements engineering

It is mandatory for us to start with the Preparation. Research the business domain by touching on:

• General knowledge, terminology, best practice – books, articles, white papers.
• Company knowledge – training sessions.
• Market intelligence and due diligence:
• Extended network – use external consultations.
• Analyze competitors – install software or subscribe to SaaS to play with it.
• Documentation Analysis: Read all available and preliminary information from the client.

The focus is on terminology, typical scenarios and use cases and best practices. The next phase is the actual Workshop. With the acquired domain knowledge, draft the checklist with preliminary questions to help prepare the agenda with the input from the business on what they want and know best what needs to be shown.

Apart from learning more about the desired business outcomes and functional requirements, the Functional Blueprint assesses the level of requirements from the stakeholder’s environment and allows for the design of the Requirements elicitation.

3. Resourcing model

Scenario 1: The client knows its business very well. Engineers from the delivery team know very well the technology and tools. Therefore, the client will serve as the requestor and they will elaborate requirements to the technical team.

What are the pitfalls of this scenario?

• The client is too busy or working at a high level to articulate requirements in depth.
• The client assumes the outsourced engineering team knows what is known by default.
• QA draws knowledge of requirements from engineers and is ultimately testing what developers think they should have built vs. testing what the client wants.

How will the challenge be tackled? An intermediary approach should be adopted: one or more employees with a central point of contact and authority for requirements gathering on the delivery team’s side.

Scenario 2: For a special team of a business analyst, a system analyst or a requirements engineer, together with the product owner and product manager engage with drafting the development plan.

What are the pitfalls of this scenario?

• The setup is not lean or agile. It will lead to additional resources allocation and cost.
• Overlaps with roles on the client-side could lead to a clash in duties and outputs.
• Knowledge is transferred between various parties, which would add one or more links and each transition loses momentum and dilutes the outcome.
• Knowledge from the early stages (the presale, discovery or scoping phase and negotiation phase) is lost.

4. Requirements’ format

There is a multitude of formats, notations, and styles to describe requirements. Some technology stacks bring their own specific methods but some don’t. Estafet’s Functional Blueprint steps on the “common sense” approach and applies a strong understanding of the technology stack to select or design the right output.

The Functional Blueprint creates an environment in which requirements are traceable. This is particularly important as the ever-evolving business world brings change to every project. No matter how it is handled (agile, or change request to the fixed scope) the changes and processes need to be understood and reflected in the baseline. The information should be available and presented in such a way that allows for connections, natural business flow, and dependencies in the requirements to be tracked and reflected upon.

5. Culture and principles

The team tasked with ensuring requirements excellence is specially trained to apply the company culture, values, and principles.

The principle

Founded upon acquired knowledge, principal activities, and techniques will be selected based on the situation:

IF the Big Picture is missing (various details available) ⇒ THEN process modelling is incorporated into the business process design, activity and sequence diagrams.

IF the Big Picture is clear at a high level (the client doesn’t yet have the details) ⇒ THEN brainstorm to invent requirements through joint creativity workshops, and a design thinking approach.

IF the Big Picture is clear at a high level (various parties should produce the details, conflicting priorities) ⇒ THEN interview focus groups, and conduct surveys and questionnaires.

IF the Big Picture is clear at a high level (information is available, encapsulated in legacy systems) ⇒ THEN Interface study and Reverse engineering.

IF the Big picture is not clear (need to see first, need to experiment and account for what-if scenarios) ⇒ THEN Prototype.

The Functional Blueprint also implicitly* conducts requirements analysis to check for conflicts or inconsistencies, specifications gaps and validates during the dialogue with the customer in written specifications.

*Implicitly means no introduction of additional project phases for analysis, specification and validation with timelines and milestones, dependencies and complexity to administer. It just includes more effort, focus and know-how in a lean and pragmatic way during the elicitation activities and will ask for the same from the other counterparts.

Tips to improve your plan

• Don’t omit the obvious.
• Terminology and language are important.
• Don’t cut corners: with requirements, it is better to do now, than later.
• Align requirements with technology.
• Business domain knowledge is important – get it any way you can.
• Know your stakeholders – who to ask for what.
• Keep track of environment – assumptions, risks, external factors.

The benefits of having a Functional Blueprint

There must be a solid alignment between the business vision and objectives and the actual delivery organisation. Having a strong project management approach will ensure the scheduling and planning of tasks are in accordance with the business goal and produce a strong estimation of the work ahead.

Here is what you can achieve when you consider a Functional Blueprint:

• Correct estimations for resources, time, and work.
• Dependencies are considered in full.
• Resourcing: headcount and complete resource profiles are identified correctly.
• Performance metrics are correct.
• Validation is intact as the QA test cases are clearly defined based on requirements.

Summary

Estafet’s Functional Blueprint is meant to help reassess and rethink the short and mid-term development goals and ensure that they align with the vision of the product. Businesses want to remove the undesigned misfocus arising from multiple feature requests, clients’ wishes for enhancements and new functionality while at the same time sustaining a strong delivery focus on clients’ and investors’ promises. The Functional Blueprint is a live document that needs to evolve as time progresses and milestones are achieved. At any given moment in time technology development must ensure it is delivering against the business vision and any deviation that arises needs to be carefully considered.