Information flows like water. If you follow the flow of information in any company, whether it's a startup or a large corporate, you'll quickly identify where the improvements need to happen. When you are pushing for innovation removing any inefficiencies becomes absolutely key in getting what you need done.
Whenever I have landed in a company in a senior position, no matter my role, I always look to understand how decisions get made from the sale through to the delivery. I do this because it has a huge impact on how I do my job, which generally involves deliving something to the market. If I don't understand the map, how could I be effective?
In this post we'll dive into the importance of the information lifecycle, how to go about getting an understanding of it within your organisation, and then how you can move to improving this flow. The end goal is more efficient delivery which drives innovation.
Understanding the Information Lifecycle
Let's consider rivers for a moment. There are various sources of rivers including melting snow, rainfall and underground springs. The water then flows through a network of streams and tributaries before eventually reaching the ocean. During this journey various obstacles are encountered: rocks, fallen trees, dams. All of these disrupt the flow and slow it down, with some even altering its course along the way.
When you look at an organisation, the flow of water is information itself. The reason any company exists is to serve the market, so the market as a whole becomes the source of information. This can be from direct sales prospecting, existing customers or new product development done internally through research and interviews. Once the sale is done, it gets handed over to the next departments, for example legal and billing. After that, the provided service needs to be delivered and the customer supported.
Depending on the complexity of the organisation, this could be a single stage or multi-staged process. The client needs to be onboarded, integration needs to be complete, and the client moved live from any staging environments. If this is a new product, the product should be developed, tested and delivered. This should be done in as short a timeframe as possible, as clients change their mind and any market movement might make your product not applicable anymore.
One of the most important and often most overlooked stages is next: client support. How well you treat your customers when they are your customers is way more important than getting them in the first place. Client services have their own challenges: product queries, billing queries, debugging and dealing with disputes to name a few.
Running this exercise in your organisation could take a few months if it has a complex structure. You should do it as completely as possible - it might be updated as new informantion comes to light - but having a solid understanding of this is crucial for the next steps.
Identifying and Addressing Blockers
Once you've got the flow done through your organisation, it should be clear where the blockers lie. You shouldn't be surprised that if you look at a given process, 80% of the time could be taken up by one stage during the lifecycle. Let's look at a simplified example below:
- Sales team go to market. All material is readily available, no custom preparation has to be done.
- Customer agrees to sign. Due to the nature of the product, pricing is opaque and needs to be gathered from several parties. Contracts need to be drawn up once the pricing is agreed, this happens automatically.
- Customer is onboarded. There is manual verification needed, but once the client is on the system it is self-service.
- The customer needs support. Queries come into customer service, and customer service has all the relevant tooling on hand to satisfy the request immediately.
For most companies, this is a very good scenario: only two steps would result in extended timelines and the fixes are both technical. On pricing, a calculator could be built to take into account the nuances of the product. The cost of this would be offset within a few sales, assuming two things: it's a relatively simple tool (even an excel spreadsheet could work) and each time the pricing is asked for it results in a 3 hour delay.
The delay here is not just the time it takes to get the pricing, it is the cost of having a manual process in an otherwise automated fashion. You will likely need to have someone request the pricing, wait for the response, and when the response comes in enter it back into the workflow. Contracts could also be done in parallel, with an addendum that contains the pricing.
The second area for improvement would be the manual onboarding of the customer. For some products this could be hours, for others this could be weeks. Understanding the requirements for onboarding could be an information flow task in itself: who are the parties involved, what are their requirements, what part of their processes are manual. Do the same exercise for this, and tackle the improvement of this flow as an internal project. Calculate the ROI to easily sell this work into management.
One hidden improvement in the above is in customer service. What are the queries? How often do they come in? What is required to answer these queries? You'll likely find that there are a large number of similar queries that could be answered through a service or through your product itself (by adding additional functionality within it).
The above scenario tackles problems that can be resolved through automation, but there is another type of problem: process.
Process problems come in when the flow of information diverts where it needn't. This often happens due to new processes or organisation restructuring where an old process remains, resulting in flows that don't make sense. For example, during a particular part of the product sales cycle three internal stakeholders need to give approval and feedback. Why those three? What do they need to approve and why? Why at this stage and not later? You'll often find you need to work on the process itself for the flow to be smooth, and these generally take longer as you are dealing with something ephemeral like process and not something like code.
But through working on processes, you are changing the DNA of an organisation. Technology can only be an addition to an existing process, whereas working on the process itself can give far greater improvements.
The Approach And The Implementation
Once you've identified what needs fixing, you need a plan to deliver to the organisation. I've written about this in detail before, but here is a high level approach:
- Identify if it's a process or a technology fix.
- Have existing KPIs on hand, normally how long the process takes is sufficient.
- If it's process, get everyone in the room (the more senior the better) and get to an agreement on what to do.
- If it's a technical fix, get a good understanding of what technology would be applicable, and work towards delivering this within the organisation.
- Trial the new approach for a few months, measuring the KPIs.
- Adjust the new approach (what) if necessary, making sure that the implementation (how) is followed correctly. If it there are difficulties in implementation, adjust if needed.
- Present KPIs to relevant stakeholders, if you need more budget have the figures behind you to back you up. Create a case study to have on hand for any future improvements.
While this list may seem straightforward, in a lot of organisations navigating the above is a significant amount of work. Patience, understanding how things are done within your organisation, and selling the benefits appropriately will help you get there.
Understand how things get done in your organisation is crucial to getting your job done. The more understanding you have, the bigger impact you can have. It's a question you should ask regularly: where does the information flow the smoothest? What can be done to make the other parts of the flow smoother?
Working through this exercise will help you not only deliver faster, but bring large value to your organisation and ultimately make you more valuable.