Business Analyst Community & Resources | Modern Analyst

Use Uncertainty to Win Business

Featured

23521 Views

0 Comments

62 Likes

The problem statement

When an IT services company fails to win new business, the first thing hurt is the forecasted profit and, out of this, a great deal of collateral damage is caused. However, the symptoms appear for the management team usually in other forms and also with delay, after a number of lost opportunities. The fundamental problem resides in the quality and the execution of the business wining process, by not knowing which project to start or where to allocate critical resources, and it starts with poorly defined decision paths and ineffective information flows.

When analyzed in detail, the lost opportunities seem to pertain to the same clusters of problems:

a) Lack of internal transparency of project estimates: values appear too high for the sales team to continue or there is inconsistency when another team executes the same estimation exercise

b) Forced team commitment is given while the bid team misses information about the client’s needs and lacks requirements to create meaningful estimates. This creates a problem later if the bid is won, resulting in customer and team dissatisfaction, as well as potential financial loss

c) Long delays are encountered in the process: estimations takes too long to be obtained and are team dependent; also, when clients’ priorities change, a “restart” of estimates from zero is necessary

d) Uncertainty is covered with money independently at different stages, bloating the overall figures unjustifiably

e) Wrong team shaping: mitigating risks with inflation of senior roles, resulting in too expensive teams; not taking into account productivity improvements over time, resulting in excessive cost and duration

f) Numbers without context: not having a transparent coherent story to tell to the customer, next to the numbers themselves, is a sure way to fail

The idea in brief

A bid is like a product that, once designed, the team must be able to deliver it. This delivery includes manufacturing the product, testing it, preparing the marketing for the product launch and finally launch it. We propose a staged approach that replace guessing a number with qualitative investigation. The model suggested, distilled from experience, shows how estimates are transformed into effort and, ultimately, into a coherent story with a price tag attached.

Focus on transparency and developing a set of principles builds a powerful team that can make real commitments, and demonstrate active ownership. Articulating each stage, helps the cross-functional team members to get the context fast and contribute towards the same goal, addressing the need for guidance.

The 5 dimensions of uncertainty that help you win business

Think about the following situation: you are given a sphere and you must estimate how much it weights. You know the sphere is made of a blend of materials, but you don’t know what the materials are, the distribution inside the sphere, and the percent of each material is. You are only allowed to drill 5 holes into the sphere and study the samples obtained; no other interaction is permitted.

The point being: it’s one thing to know that information exists and it is accessible; it’s another to use it effectively. The same can be said about a bid process, you are allowed only a few “drills” and based on the unique knowledge obtained, you need to shape and present the commercial offering.

Take the time to get on track and craft a conversation that matters. That conversation has to be about the topics that matter most in a software project, the uncertainties:

Given that statistics show us the only thing certain is that uncertainty exists in each area, it seems worthwhile to investigate them furthermore. Do not cover uncertainty with effort in man-days (and, implicitly, money) just to work towards a “magic number”; adapt the approach to suit the known facts and for the rest add actions with mitigation and outcomes. Through this, you gain the ability to share openly the uncertainty aspects with your colleagues and the client rather than hiding it non-transparently in a figure.

This approach - to replace guessing a number with qualitative investigation - produces an end result that is easy to understand and manage and also supports the segmentation in parts that are much more resilient to change.

These areas are common to most projects and, as stated before, can be considered “clusters of uncertainty”. By examining each cluster and breaking it into components, we can provide more transparency to the bid. Let’s look briefly at each:

For each of these areas, most companies have access to historical information that could be harnessed to win new business or consolidate the existing ones. Answering the questions “What data can we use from what we have captured?” allowed building a simple scale to evaluate each dimension of the bid.

Commercial

Estimated revenue – For the IT services companies, the main pylons that stand for a project are:

The forecasted profit, directly linked to the estimated revenue

Long term strategic goals – such as gaining more business with the same customer of within the specific business domain

For example, a low-revenue project for a new strategic customer might be favored over a high-revenue project for a customer unlikely to supply further work. The approval path for a new project can be shortened or lengthened based on the deviation from the strategic company goal; the wider the gap the more will take to get approval.

Client geography – While working in international companies and projects is a common thing for our generation, there are still elements to be considered:

Time zone differences higher than 6-7 hours will increase the difficulties in having meetings with the customer and increase the feedback loops

Even if most work can be done remotely, some on-site visits are like to be needed, especially in the pre-sales phase – increasing the cost in detriment of the project’s margin

Legal constraints might apply for given countries Last, but not least, taking into account appropriately the cultural differences can make the difference between success or failure

Expanding into a new geographies often takes a great deal of time especially if this is first time the new market is tested.

Type of contract – Both the client and the supplier are likely to have preferred types of contracts and, often, they are not the same. The type of contract dictates the level and area of risk that each party is taking. For example, if the contract is Time & Material, the suppliers takes on a reputational risk while the client is bearing the financial risk – if the work done by the supplier is not satisfactory, it is likely no future work will be contracted, while the client is would lose most of the financial investment done on the project up to that given date.

Business and client

Client context – A known client enables the vendor to easily navigate the it’s context and this can speed things up and facilitate closing the deal. Existing or returning client means the company knows the business stakeholders and has done with them business in the past. In the same time a new division of an existing client can be considered as a new client. In the longer term clients tend to return to the same vendors to buy more if the previous contracts have been fulfilled successfully; as they see a commodity to work with known procurement, change management and governance processes

Team augmentation or ramp down is not considered a project bid in the sense that it usually falls under the responsibility of the existing vendor project team.

Business context - is a combination of domain knowledge and business model. The domains are the functional areas the project is addressing (e.g. finance, telecom, insurance) and the business model is how the client does business with his clients (e.g. B2B, B2C, B2B2C).

Without having a coherent view of the client’s business functions and domain, the vendor is not in a position to understand how to use technology to innovate and solve the needs of the client.

Requirements

SDLC model – This is the software development life cycle under which the solution is delivered to the client. It needs to be recognized that in some cases client-specific or hybrid (mixed) models apply. The uncertainty here usually sits in the different understanding and different practices that are undertook by client and vendor to deliver software projects. In this case common sense should be applied when selecting the value for this category.

Functional requirements – Beside the actual requirements that describe the situation – the boundaries of the system, the problem to be solved and the future desired state, it is useful to consider also the way the client approaches the requirements documentation as a whole. There are various scales to define the requirements maturity model that ranges from ah-hoc activities, no tools and no standard deliverables, to applied, measured and continuously improved requirements management process. It is important to know where your client is situated on this scale, what they proficient at, in order to augment their organization in term of skill set and put the existing tools to best use.

Non-Functional Requirements (NFRs or Quality Attributes) – These are attributes that pertain to the qualities of the delivered solution. It is essential to distinguish in this category whether the requirements are consciously chosen or potentially “copied” from other projects or NFR databases. If in doubt, the client should be directly challenged on this category. As the bid project progresses, both client and vendor understanding of the scope is enriched and that often lead to discovery of new quality attributes or adjusting the existing ones.

Technical

Technical ecosystem - Technologies include everything from programming languages, libraries, frameworks, dependencies on other tools. The code base consists in existing lines of code. The technologies mix in it must be qualified and defines the "footprint" of these technologies in the overall picture of the system and with vendor overall knowledge in terms of staff skills.

Technical Documentation - Has to be reliable and up-to-date otherwise consider no documentation is available.

Platform and deployment (DevOps) - This is a mix of the following: Platform topology, Deployment mechanism & discipline, Build automation, Quality tools & measurements, Volatility of VM environments, but not limited to In order to gain more clarity and to create a structure the vendor can start discussing with the client about a continuous delivery maturity model, and then decide where to place the bid accordingly.

Estimations

Estimate class – The confidence factor interval is important when assessing how useful (and risky) an estimate is and how different the implications can be. If the type of contract is “time and material” the estimation class affects the budget at the client. It is therefore essential that the bid team makes the confidence factor interval visible and as well as the reasons that go with it. It should be noted that research in this area has confirmed that there are limits to the precision possible dictated by the understanding of what needs to be delivered. It is therefore important to have a structured conversation with the client to understand where the requirement in precision comes from and what can be done to narrow the gap.

Evaluation of the scenario

Apply the proposed framework on the bid, taking into account its known facts and attributes, and build a RAG evaluation scenario report by giving a red, amber or green status to each area. This will indicate where you need to focus your efforts and the level of details needed to complete the BID successfully.

Example:

This example indicates that you need to focus on the technical aspects, as well as the accuracy of estimates. The client and business seems to be known, as well as the delivery model. Project commercials of a medium complexity are not expected to bring many challenges, but an eye should be kept open.

Bid proposal - story with a price tag

The model proposed serves to main purposes: it helps you understand in which area you should concentrate the “drills” in order to gain the most valuable information and it provides the base for writing the proposal story.

Even with a bullet-proof contract protecting them against financial lost, the client is still risking an even more valuable commodity when deciding to work with a supplier: time. This is why, next to the price tag itself, the story that accompanies the proposal is key in winning new business for a supplier. It shows the level of experience had providing the IT services, but also the supplier’s values – such as transparency and the focus on customer’s satisfaction.

Using the qualitative investigation model is the way to ensure the story presented to the customer reflects the understanding of the bid team, revealing the uncertainty areas as well as the known facts, and invites the customer to accept the supplier as partner in the journey of discovery, having as main objective the client’s satisfaction.

Authors: Iavi Rotberg & Alina Horbovanu

Iavi Rotberg: Energetic, resourceful and performance-driven Business Analyst and Product Manager with an entrepreneurial spirit having proven 15+ years’ experience in the market. Focused on discovering, managing and continuously improving software solutions for large enterprise organizations.

Find more details at: https://www.linkedin.com/in/iavirotberg

Alina Horbovanu: Senior Project Manager with experience in Telecom, Banking and Insurance business domains, Prince 2 practitioner certified and with IT software development background. Work experience in IT companies of different sizes, from startups to international companies, located mainly in: Iasi, Timisoara and Paris.