Solution Architect? I’m a Value Architect!

In my solutions, I concentrate on the value our clients. I learned this lesson the hard way. Now, I’m designing solutions and proposals with a more structured approach that focuses on the outcome for our customer.

I remember a time while working as a Management Consultant and I had to prepare my first proposal. We received an RFP from a manufacturing company and I was part of the bid team, supporting the solution and writing the documents.

We were working in our office in Munich, on a hot summer’s day. When I was assigned the proposal, I felt so happy because by working on an RFP I was directly taking part in fulfilling our growth target.

We did not shape a solution, we just reshaped delivery

The bid team was young, but fully motivated. The RFP included work we were already familiar with and delivering for a few years prior. We used the FTE numbers that our delivery was providing, optimized the staffing pyramid and used the latest deal financial figures. On top of this, we calculated the additional tasks the customer was requesting which were not yet in our scope. This was our offer. During the proposal writing phase, we never thought enough about the changing needs of the client and the different options our company was offering. We did not align the value proposition for the client, nor did we define all of solution components. Our bid team was inexperienced in working with bids.

We failed often and we failed late in many interactions

We finished the solution design and proposal including FTE and a price calculation. After working on it for three weeks, we discussed the solution with the client for the first time. It soon arises that his need was for more flexibility and better quality.

This changes a lot, and we had to add different solution components such as joint demand planning, tools based source code quality reviews, additional reports, KPI’s and different other components.

After the next full blown iteration, we had to change the solution components which were fixed in their price and which were in the optional scope based on T&M. Now, it was already late in the RFP process, and there was an ongoing in and out status of tasks; changes in the fixed price and optional work. In other words, it was a mess.

We lost the RFP because we weren’t structured and did not understand what the client was asking for. We posed our questions too late and each week we had to ask new questions. Furthermore, we worked many extra hours because of ongoing changes to the solution.We had been beaten to the ground, feeling somewhat useless as we had put so much effort into the response of the RFP, but did not succeed.

An alignment upfront on the approach is as important as the approach itself!

What we miss frequently is that all members of the bid team have to work in an aligned manner in the same solution process. This is only possible if the approach is well structured and understood by the entire team:

1. Define the value proposition
2. Add solution components to the value proposition items
3. Define the tasks in scope
4. Split the solution components in the pricing models
5. Calculate the number of FTEs
6. Define the required skills and the shoring

Value proposition are the condensed requirements of the client. Often you find them in the RFP itself. In outsourcing we mostly encounter cost reduction, gaining flexibility and the need to increase the quality of the service.

Solution components are the different services and items that our company is offering. It’s the answer to the question on how you will deliver the value proposition, e.g. how are we reducing the costs for the client?

We are sticking these components together (as if Lego bricks) to fulfill the client’s needs which are defined in the value proposition. The solution components are changing the effort and they are adding value to the client.

Scope must be clearly defined. Which task per solution component are we doing which will be done by the client or a 3rd party. This has an impact in the fixed price but also on the rates we include in our blended rate or rate card. E.g. a business analyis requires another skill set then agile-testing or automation.

In large proposals with different solution components we have the need for more than one pricing model. For example, one part is offered as a fixed price, because the scope can be clearly defined. Likewise, the development of minor new enhancements for new software is unclear in the scope, so we offer a blended rate based on T&M. Later in the run phase, we might change this part into output based pricing.

Based on the solution component and the pricing model, we are calculating the FTE’s. Now it is clear for what we offer one fixed price. In all fixed price solution components, a detailed bottom up calculation is mostly required. In addition, we are adding solution contingency / a risk buffer. In T&M areas, another approach might be sufficient. Gain sharing components may require different calculations.

This approach is completed by defining which skills we will need at which place at which time. If we know that high quality is requested by the client, we might end up with a higher onshore ratio or a higher seniority in the team.

This process seems simple and obvious but in a hurry, I have seen things are getting muddled up.

In my last deal, all elements were getting muddled up. Starting with the FTE calculation and then aligning the solution components was generating unrequired iterations. As an example, if we bring in automation we need (at the beginning) automation experts and later in the delivery stage less test experts. Early on, the discussion on the pricing model and the components which are included needs to take place.

What follows below is a simplified example to show the relationship between (1) value proposition, the (2) solution components and (4) pricing model. The other parts of the approach are not shown to illustrate the best way of thinking.

Simplified Example:

By bringing the value proposition together with the solution components, we never lose the focus on the client. Our line of argument is clear structures and easily comprehensible. We know for each component why we are using it and which benefit it should deliver.

Are you always following this process? If not — why — and what was the impact on your solution? What can be improved?

About the author: Florian Hoeppner is located in New York, USA and was a full time Solution Architect for Application Outsourcing in Financial Services. He is now working as Technology Advisor for New IT in Financial Services. He started in the year 2000 working successful in IT domain for multinationals and has experiences in consulting — CIO Advisory, Transition and Delivery mainly with the topics IT Sourcing-, IT Shoring-Strategy, Supplier Consolidations and Agile Transformations. Additionally he has around 4 years experience in the area of Financial Services and as entrepreneur with a FinTech Start-Up.

Articles and comments are my own views and do not represent the views of my employer, Accenture.