Category Archives: FileBound Document Management
Accounts Payable Automation is the process of re-engineering the accounts payable process to create and improve efficiencies. More often than not it involves digitisation and centralisation of a process that is currently manual and paper-centric. When done correctly an AP Automation project is not just automation of the current process, it is a complete re-imagining of the process.
Organisations are drawn towards AP automation projects because they offer a very large set of potential benefits. These benefits include cost reductions, accuracy improvements, resource reallocation, improved cash management, access to early payment discounts, avoidance of late payment penalties, improved vendor relationships and increased staff satisfaction just to name a few.
Unfortunately for most organisations they need to run a change project before they can access those benefits. This can be challenging as history tells us that approximately 50% of change projects lead to frustrated delivery (failure to deliver on time, to budget and / or the full scope) or completely failed delivery.
We have put together our top tips to avoid being in the 50%. Here they are;
1. People Leadership.
It should come as no surprise that people leadership sits at number 1 in our list. Despite the significant advances in labour management since the Industrial Age we are still seriously deficient in the way we lead our most valuable resource through these change projects.
If you want to improve your people outcomes on a project then you need to start the communication about the project (what it is, why it is needed, how it will impact the individuals etc.) with the team early on and where possible engage them in some of the decision making. It is important that organisations also let the team know what the non-negotiables for the project are. Allowing team members to think they can change an outcome that is a non-communicated non-negotiable is just a waste of energy that will become a massive de-motivator for the individual when they eventually work out that it is non-negotiable. For this I will use the Bus analogy. The team need to know that the bus they are on is going to a new destination. They need to know that the destination is not open for debate, however, what is open for debate is some of the semantics relating to the journey. e.g. which seat they will take, will there be stops on the way etc. Having the courage to engage the team early will lead to superior project outcomes.
Your project team will need good levels of Executive Support. The key people on the project need to know they have the backing of the executives. They need decisions made in a timely manner and required resources made available to ensure success. They also need executives to step in where needed and remove roadblocks.
Engage your IT department early. In our experience the IT department will be a great ally on a project like this if they are engaged early and are able to make sure their input is heard. The modern IT department is usually very concerned with delivering business value and they will want input. On the contrary, bringing the IT department in late will lead to your frustration as you have to wait while they go about their normal checks and balances.
The final people leadership tip we have is to look after your Subject Matter Expert (SME). Most organisations have a person that is central to the successful operation of the current AP process. This person will be in high demand as you set about planning an automation project. They need to provide significant input into the project. The problem is that these key resources are generally already over-utilised in their normal working week. Having them contribute a significant effort to your project will leave a big hole in the current process that will cause many issues. What normally happens is the day-to-day operational issues take priority on the project and the project slips well out into the future. Good leadership here plans for this resource issue by back training other resources into some of the key components of the SME’s current role. That allows them to be freed up to participate in the new automaton project without significant negative impacts to the organisation.
2. Consider Cloud Deployment.
Research* has shown that cloud delivered AP solutions are 100% more likely to deliver real time visibility into an organisations cash position. This is just one of the benefits that organisations can enjoy when they choose a cloud deployment model.
A cloud deployment model will provide stakeholders access to information when they want it from anywhere in the world. Any modern cloud based solution will offer mobile access to information as well as allowing staff to process their workflow tasks on their mobile device as well.
A less known but hugely compelling reason to choose cloud deployed solutions for AP processing is based around the skills required to maintain that type of solution. Corporate IT Departments have many IT skills but few of them are specialists in document capture, document management, workflow and data integration. When these technologies are deployed in the cloud your cloud hosting partner will have these skills. That way when there is an issue you can rest assured that the right resources with the right skills will get it resolved quickly.
3. Choose an Integration Capable Solution.
Even if your first project stage does not require integration with your ERP, it will likely be a future need. AP automation solutions that provide maximum ROI need to access vendor, PO, receipting and other critical information from the ERP so that they can make informed approval routing decisions. They will also need to be able to pass electronic invoice data back into the ERP so that human labour is not needed to do it. None of this can happen if your solution does not have a strong integration capability. This capability will also be essential if you plan to use the implemented platform to automate other key business processes. e.g. HR Automation, Contract Management, Customer Service Processes. In the information Age companies that are able to effectively connect their technology have a significant advantage over those that cannot.
4. Partner with a Trusted Advisor.
Generally an organisation will only run one AP Automation project and it is impossible for it to be a core skill of the organisation. There are a number of companies, like ours, that do plenty of these projects. Probably the biggest influence on your potential success will be the quality of the partner you choose to do the project with. Engaging a company like ours will enable you to tap into decades of process re-engineer and technology deployment experience. When deployed for your benefit this experience will underwrite the risk associated with running such a large change program.
Hopefully these tips help you deliver a successful AP Automation project. If you would like to meet with us to discuss your specific project please email us at email@example.com.
*Ref. Aderdeen Group 2015, Bring Invoice Processing Costs Back to Earth with AP Automation in the Cloud.
So, you are going digital. You have started or completed a project/s to implement digital solutions. You and your technology partner have analysed your requirements and worked hard to test and turn on a digital platform. But what then….
One item often overlooked when implementing digital solutions is the changing environment within which they will work moving into the future. You see from day one of your new systems’ use it will start to have a decreasing ROI. This is due to the unstoppable changes in the environment in which this solution now operates. This environment includes the organisation, it’s people, it’s other processes and the external environment which can include things such as the legislative environment.
So, we have implemented a solution and we know that everything around that solution will continue to change causing a decreasing ROI. How do we mitigate this organisational risk?
We would strongly recommend that you have your technology partner provide a “Managed Service” for the solution / solutions.
For the purposes of this article a managed service is a contracted set of services that are provided by a solutions provider to a solution using customer. Typically, they are paid for monthly, operate as a use-it-or-lose-it facility and are used as needed to achieve specific solution outcomes.
As an Example;
A company, ABC flights, has a 6 hour per month Managed Service with their technology partner for their AP automation solution. They pay a monthly fee for this and request work against it via a web portal. Typically, ABC use this service to update invoice templates to ensure a high percentage of data is captured automatically when invoices enter the solution. They have also used it to make workflow routing changes, upgrade the software components to the latest version and seek advice from the solution experts on potential future projects.
So, who should demand these Managed Services? Well, we believe the customer and the technology partner should both demand them. They provide significant benefits for both parties. I have identified these benefits below;
Benefits to the Using Customer
An ROI that is sustained [and possibly even improved] over time. Work can be regularly scheduled to keep the system operating at peak level despite any changes to the operating environment. The Managed Service can also be used to digitise additional processes and drive even greater ROI.
Team member satisfaction with their work as the systems they use are modern and operating well. This is more important to organisations as the millennials continue to rise through the workforce. Like it or not, this generation expects their employers to be digitally savvy.
An ability to ensure you are maintained onto the latest versions of your software components. These versions generally have significant security upgrades as well as a slew of new and improved operating functionality. Whilst most organisations understand the importance of software maintenance, far less of them ever actually implement a regular upgrade process to ensure they are on the latest versions of their software platforms. This is often due to the cost of a technology partner implementing these upgrades. With a Managed Service, these upgrades can be done as part of the service thus ensuring the customer continues to reap the benefits of their investment in software maintenance.
Priority of work request processing with your technology partner. Your technology partner will definitely process their Managed Service customers in priority over their non-contracted customers.
A smoothing of cash-flow relating to the operation of the solution. Even if you do not have a Managed Service it is highly likely that at some point in time [usually when there has been a big problem] you will need to spend a quantum of money maintaining the system. This work is generally not budgeted for.
- A solution that adapts to the changing environment
- Maintained, reliable systems for workforce use
- Timely access to improved security and new / improved functions
- Priority response from technology partner
- Improved cashflow for solution maintenance costs.
Benefits to the Technology Partner
A happy customer that will often act as a referral customer. In our experience, our active Managed Service customers are easily our happiest. They get everything they want, when they want it and when there is an issue with the solution we don’t waste time trying to work out who is paying, we just start work. Having a Managed Service means that the technology partner can be at their best when things are at their worse.
The ability to resource accordingly so that service requests can be dealt with in a timely manner. When a technology partner has a critical mass of Managed Service customers they are able to staff their engineering departments with stable, high quality solution engineers. If a technology partner only ever does project work it is much harder to ensure adequate staff levels for peak demand.
Significant increases in customer delight. As well as all the standard benefits that accrue from a happy customer there are also lots of efficiency benefits that accrue. An unhappy customer needs a lot of management. Most of that organisational effort is nonchargeable and diverts organisational effort away from strategically important tasks [like growth].
Reduced commercial risks as deployed solutions remain valuable for the length of the agree service contract. There are less late payments and discount requests as the customers are happy.
A potential case study target. One of the most powerful things a company has is its customer success stories. It is these stories that often provide the confidence and credibility needed to succeed in attracting new customers.
- Turns customers into advocates
- More effective technical resource management
- Reduce customer rework costs
- Significantly reduce commercial risks
- Create case study opportunities
So, there are many benefits to Managed Services however there is one key element that needs mentioning for those customers considering using one – A Managed Service is only valuable if it is actively used by the customer. Failure to use a Managed Service just leads to an unjustifiable organisational cost.
As we continue down the digital transformation path, more and more organisations will be implementing digital work solutions. These work solutions need to give great ROI and ensure that any human labour required by solution is deployed on high value tasks. First-world economies need for this to happen if they want to be able to maintain high wage levels.
Organisations that want to ‘Win’ in the information age need to implement solutions that deliver great ROI, delight their staff, adapt to the changing world and maintain high levels of security. Implementing a Solution Managed Service for your digital solutions is the best way of maximising your organisation’s chances of being one of the ‘Winners’.
Do you have any experience with Managed Services on Digital Solutions? We would love to hear your story.
Contributed By: Lee Bourke, CEO, FileBound Australia.
If you spend your days going from demonstration to demonstration and are continually frustrated that your close rate is not high enough then this article may offer some insight that can help.
Last year we ran an education event for our partners titled “Demonstration Masters”. The goal of the event was to show the attendees how to run solution demonstrations that significantly improve the likelihood of a sale. After all, isn’t that the primary goal of any sales activity.
To prepare for the event we researched the subject matter and then added our prior experience into the mix. Whilst a simple article on the subject cannot pass on all the content we delivered through the event I am going to identify the major themes that we delivered here so that you can start the journey to improving your solution sales efforts.
A quick note before I do that: What I am talking about here is the Technical Proof demonstration. That is a demonstration to prove the credibility of a solution. I am not talking about the Vision Generation or Spray and Pray types of demonstration. In my view the Vision Generation type of demonstration, where you show prospects a range of solutions you can deliver and hope they like something, should be used for lead generation in many to one events like boardroom lunches. I would avoid Spray and Pray demonstrations, where you basically show a prospect all the software features you can cram into an hour, at all costs. They are a very costly and ineffective way of doing lead generation.
Don’t demonstrate too early
Eliminating this bad habit is the number one way to close more deals. What we see in market is well intended. The sales lead finds a pain or opportunity that they know their organisation can solve or resolve. They tell the prospect about their capabilities and the prospect is interested. They then consider the next step here to demonstrate the software as soon as the prospect will allow it.
The problem with demonstrating at this stage is that you do not understand the problem at a granular enough level that you can build a CREDIBLE solution. If your solution is not credible then your competitors have an opportunity to beat you to the sale. Even if there is no competitor in the deal you will most likely convince the prospect to do nothing as they have not seen the solution to their problem.
You also need to consider your timing of the demonstration. There are times that are not wise to demonstrate to certain prospects e.g. end of month for a finance team or times where key stakeholders are on leave. There is no point securing a demonstration time that fails to allow the key stakeholders to attend and be attentive.
Opportunity discovery is key to demonstration credibility
The demonstration represents a unique opportunity to blow the prospect away with a credible solution to their problem. To build credibility you need to spend a lot more time doing discovery. The goal of this discovery is to build relationships with your prospect and learn as much as possible so you can reflect that knowledge in your demonstration.
Present, Future and Preference
A straightforward way of thinking about what needs to be discovered is Present, Future and Preference. You need to understand their present situation, their envisioned future state and any preferences they have for how they get to the future state [i.e. a mandated cloud strategy for deployment].
Demonstrate a real ROI
Remember that when we talk about Present, Future and Preference we are not just talking about the technical stuff. You need to understand who the present and future players are in the organisation. These are the people who need to assess your solution. You need to understand the industry they play in and what the future of that industry looks like. Helping a prospects executive understand how they can win in their industry is a great way of becoming a highly valued trusted advisor.
Hopefully in the discovery stage you have managed to determine their ROI preference. Your job then is to make sure you demonstrate how that ROI will be achieved. Helping the prospect meet an ROI requirement is a key enabler for sales success.
Demonstrate only what customers need to see
I can’t stress how important this section is. I want you to think about all the software demonstrations you have sat in over the years. Think about how similar they are. A PowerPoint deck with company credibility statements followed by a run through of basic software functions followed by more complex functions and then finally a demonstration of how the software may solve the client’s problem. By the time, you get to the good bit you have very carefully put your prospect to sleep. We need to stop this.
Try turning things around. Get your prospects into a demonstration and start by showing them how your solution solves their problem. You will be amazed at what happens when you do this. If you have done the discovery diligently you will get an outstanding reaction. Trust me. I have been doing my demonstrations this way for a few years now.
You can still have your slide deck handy and later in the meeting the prospect may want to know more about your organisation and your history. By reversing the order, they will likely be more interested in this information as they are seriously looking at you as a potential solution partner.
One of the analogies used by Peter Cohen in his book “Great Demo” (see below) is that of an onion and the demonstration being the peeling back of the layers of an onion. You show the solution first (layer 1) and then you show other layers the prospect asks to see so that they can complete their assessment. You stop peeling layers when the prospect stops asking. Do not show them layers they have not asked to see.
Hopefully these tips will help you improve the quality of solutions you deliver into market whilst also allowing you to improve your solution close rates.
Final note: Remember the demonstration represents the best opportunity to prove yourself and your organisation as the most credible partner to help the prospect solve their problem or take advantage of their opportunity. Conversely, it is also the best opportunity to prove that your competitor is the best partner for the job. If you choose to put the extra effort into the demonstration you will beat your competitors more often and sell more deals.
To prepare for this event, we researched the four leading texts (based on Amazon sales) on the subject matter. I have included the details of these texts below if you are interested in more information.
If you would like to discuss this subject further please contact me.
Chief Executive Officer
Digital transformation of an organisation is a complex undertaking that involves a change in culture that is more profound than both the technical and process changes combined.
Most organisations lack the skills internally to deliver a transformation process and generally will rely on external parties to assist. If you accept the notion that the cultural change required will be greater than the organisational process change, then it makes selection of the right transformation partner a critical choice as they will not only need to change your processes, but more importantly influence a significant change in your organisational culture.
Most organisations would use a traditional tender process as a means of selecting an external party to assist with the transformation. Many service providers will bid for the business process transformation work, however they will give little attention to their responsibilities as it relates to the cultural transformation. Executives need to be aware of this and consider if a tender process is the right choice for such a crucial decision.
Tender processes are a common part of a modern corporate landscape. Essentially tenders are a great way of assessing the offerings of one company against another. They are incredibly valuable when procuring commoditised items. A commoditised item is easy to specify, easy to evaluate and lends itself to the creation of price competition. If, however, you are looking to procure a solution then the humble tender process, as it commonly functions, may not be the best tool for the job.
Solution procurement requires the selection of a partner that will be able to deliver an outcome where the journey to that outcome may not be readily apparent. That outcome also needs to come at a cost that is deemed acceptable to justify the project. The problem here is that it is nearly impossible to accurately determine the cost when the journey is not readily known. Tender respondents deal with this by loading up the response with ‘caveats’. These are conditions placed in the response that are purposefully designed to ring out responsibility for situations that the respondent believes are likely to occur. Add to this the complication where, generally, the team writing the tender has very little subject matter expertise in delivering a digital solution like the one being procured. This effectively creates a situation where an organisation can get extremely poor outcomes.
At the time of awarding the tender it is impossible for the procuring organisation to understand what will happen next. There is a chance that the selected party will deliver a marvellous outcome. It can, and does happen, however, this is generally good luck not good management. What often happens is a situation transpires where the selected party assumes little to no responsibility for assisting with the cultural transformation of the organisation.
In my experience cultural transformation issues are the thing most likely to cause you a significant project failure and / or cost blowout. Modern technologies allow us to solve most technical issues in a reasonable time-frame. What can’t be easily solved is an organisational culture that will not adapt to change. The respondent will not be too troubled by this as they will have placed enough ‘caveats’ into the agreements so that they will be able to bill their way through this phase of the project with very little motivation to assist with remediating any of the roadblocks.
One option available to an organisation considering undertaking a digital transformation is to focus on procuring a great partner as the highest priority. Procuring a great partner will ensure that your organisational objectives are much more likely to be met at a cost the organisation can afford. A great partner will assist you to select and implement a great solution.
One way to start the process of finding a great partner is to see how they can and do solve a single digital problem for you. If they do it well and achieve a great outcome, then you give them another problem to solve. Obviously you are able to control the selection and timing of the problems being passed to the partner and if you hit a major hurdle with that partner you are then able to try another without having to back out of a large enterprise wide contract.
Implementing a single digital transformation project will allow you to assess the technical, management, leadership and cultural qualities of your partner. Measurable aspects of these qualities can be written into the engagement as key success criteria for the implementation along with the technical aspects of the solution. If the chosen partner delivers a great outcome, then you are able to contract for the next phase building in these key criteria. If the outcome is less than great you will not have wasted a significant amount of organisational resource [time and money] to determine that you need a different partner.
Chief Executive Officer
What is it?
Requirements for a project need to be mined, compiled, analysed, negotiated, specified, validated, tracked, and updated during the life of a project. All of this has to take place within a controlled environment so that;
- All stakeholders know exactly what is to be delivered by the project team.
- There is governance placed around the authorising of changing requirements.
- The solution can be supported into the future. i.e. new personnel can read the requirements and get a FULL understanding of the system intent.
- Each requirement can be traced back to a specific commercial outcome.
What can it look like?
The method of requirements delivery will vary from project to project normally based on project complexity. As well as complexity the level or type of requirements management can vary for risk, cost or political purposes. Here are some common project requirement configurations across simple, standard and complex project categories;
Each organisation may use different document titles however the purpose and content should be very similar. Some organisations may also use a version system on each of the documents. The core concept here is that collectively all requirements are trapped and documented.
The Commercial Imperative?
The requirements delivery for a project is directly related to the projects commercial outcomes. Every requirement delivered should exist in one of the requirements documents and each of the requirements should have an associated commercial cost (even if it is $0). A problem we see too often is project teams failing to document $0 changes. Whilst they may think that this is saving time on admin they are actually causing the following potential problems;
- Future support engineers may not be able to understand what was delivered by reviewing the documentation.
- They miss the opportunity to show the client what value add they have delivered [especially if there were multiple “no-charge” changes.
- Having a change made to the deliverable without the appropriate authorities knowledge or approval.
This diagram shows the accumulation of cost [or revenue if you are a service provider] that should attach to the requirements.
What happens when we get it WRONG?
Research tells us that approximately 50% of projects have a frustrated delivery and approximately 25% of projects have a complete failure to deliver. Poor requirements management is a major contributor to both of these outcomes.
Failure to manage requirements can lead to any or all of the following NEGATIVE outcomes;
- Stakeholders feel they have lost control of the project and withdraw support.
- Unneeded requirements can be delivered.
- Critical requirements can be missed.
- Forward support of the solution can be costly and time consuming.
- The project can experience poor commercial outcomes.
- Loss of reputation from delivering a poor outcome.
The good news is that with proper planning and care any organisation can become good at project requirements management. See our other blog posts for additional related information;
At FileBound we would love to hear any thoughts you have around this subject matter. Have we missed anything? Have you noticed similar outcomes?
Chief Executive Officer
IT projects are notorious for having a high rate of partial or total failure. These failures are often born of poor project execution and can lead to any or all of the following outcomes;
- Additional resources needed to deliver the project on time.
- Additional time to deliver the project with the same resources.
- Reduced or modified functionality of the project deliverable.
As well as these troubled outcomes there is also the fatal outcome where nothing gets delivered. This blog seeks educate on the hidden costs of the poor project execution that lead to these outcomes.
Before exploring the hidden costs lets take a look at the real or understood costs. In project terms there is a golden rule relating to remediation (rework) costs. Essentially the cost of remediating a troubled project magnifies exponentially the further into the project you get before identifying the issue. For example:
This table tells us is that if we fail to discover an issue until the project has gone live then we are faced with a cost to remediate that is one hundred times greater than if the issue had been found during design. So lets assume the issue in design cost four project hours to remediate. Using sixty dollars an hour as our cost base then failure to find an issue until a solution is live could cost us $24 000 to correct.
Now those hard costs are a real problem for an organisation, yet these can often seem insignificant next to the hidden costs of poor project execution. Lets explore some of the major hidden costs of these poor project deliveries;
Opportunity cost of the project team resources
In most organisations there is a resource bottleneck in relation to high value IT resources. These resources are rarely idle and generally go from one project to the next as an organisation continues to transform itself or its clients based on the demands of their respective markets. When a project suffers from poor execution it either delays the current project resources moving to a new project or it draws in resources off another project to help with the remediation. In either case there is another of the organisations projects that gets delayed or restrained. It is rare for organisations to factor in the cost of these ‘other project’ delays when assessing the cost of a poor project deliverable.
Opportunity cost of your executives
When a project starts spinning into a troubled state it inevitably drags the organisations executives into it’s wake. These executives are the ones that need to re-organise and reallocate resources. They are also responsible for the additional communications and expectation management around the knock-on impacts of the struggling project. This all takes time and distracts the executives from other tasks. These other tasks could be revenue in nature or could simply be tasks to ensure the efficient operation of the organisation. Either way these knock-on effects can become quite costly and are never assessed as costs associated with the rectification of the troubled project.
Opportunity costs associated with sales misdirection [service provider]
If your company is a third party delivering the project for your client then there are a whole extra level of opportunity costs you need to consider over and above the ones detailed already. The largest of these is the opportunity cost of having your sales arm continue to be involved in a damaged project. If your sales team are engaged in these post sales activities they reduce the amount of pre-sales activities they can perform and as such there is a direct reduction in revenue.
Future revenue cost of reputational damage.
Often a troubled project leads to failed customer promises. These failed promises lead to reputational damage that can impact the organisation to sell its customers products in the future.
Future revenue cost of late delivery
Often an organisation is undertaking a project to enhance a listed product or create a new tailored product for its customers. Delays to these enhancements or delays to the introduction have a direct revenue implications. Notably like the previous hidden costs, these are never taken into account when tallying the costs of poor project execution.
As you can see from the above list there are some very compelling reasons whey we should all place a high premium on getting projects executed correctly the fist time around. Feel free to review the following blogs that deal with the methods for avoiding these poor project outcomes;
At FileBound we would love to hear any thoughts you have around this subject matter. Have we missed anything / Have you noticed similar outcomes?
Chief Executive Officer
As the world continues to change as does the role of the salesperson. In many ways the transformation of the sales team (and its members) is the most important transformation in any organisation for as we all know “nothing happens until someone sells something”. In this blog we will be exploring the traits of the Trusted Advisor and why, now more than ever, they are necessary traits for any professional salesperson.
So what is a Trusted Advisor? Well the name really does present the answer. It is a person who is not only trusted by others but is sought out by others for their advice. The following diagram depicts the Trusted Advisor role in terms of the relationship between personal intent and functional capability (subject matter expertise).
Now we know where a Trusted Advisor sits in the Sales landscape we need to explore the traits that elevate a salesperson to this space. There is plenty of literature on this topic but if I had to distil all that I have learned about the traits of a Trusted Advisor here is the list I would present;
1. A Trusted Advisor has intent for the long term. To do this the Trusted Advisor will seek an understanding of the prospect / customers strategic objectives as well as their tactical objectives.
2. A Trusted Advisor is a problem solver and is not afraid to lead with ideas. Trusted Advisors are malleable in their understandings and are just as happy to learn as to teach.
3. Trusted Advisors have an accountable and accessible nature. They are happy to own their missteps (and those of their team) and work transparently to correct them. They understand that when conditions are at their worst, they need to be at their best. They are easy to contact and always return messages.
4. Trusted Advisors bring the required resources to the table to solve problems. The Trusted Advisor understands that they are not experts at everything and have a strong network of accessible colleagues and technical resources they can call on to help solve their prospect / customers problems.
5. A Trusted Advisor see’s their role as a continuing role with their prospect / customer. They don’t relax once they have delivered an outcome, they simply move on to the next opportunity.
So why is being a Trusted Advisor so important now?
Well historically a salesperson would be coached to take a ‘Trusted Advisor’ position only for high value solution sales. This is still the case for these high value solution sales and is as important as it ever has been. Contrast that with salesperson selling box products. These salespeople were coached to focus on features and benefits and were not necessary burdened with taking this higher order role with their prospects / customers. This was a commercial necessity as the box product sales generally had a very low margin level and the cost of sale was very important. The Trusted Advisor approach to selling is a higher cost approach. In the past the box product salesperson had one job and that was to make sure the prospect / customer clearly understood their products features and benefits including their “Key Value Proposition”. Their role was to continue to communicate these messages so when the decision point was reached by the prospect / customer they would ultimately choose their box over all other boxes in the marketplace.
Fast forward to the modern day and we now find ourselves in a world where many buyers are able to educate themselves online. They can effectively learn about your products features and benefits (including the “Key Value Proposition”) without you. They can research other buyer’s journeys and experiences with your products globally from multiple online networks. The buyer has effectively made the traditional box product salespersons role redundant. So what is your role now?
If you are a box product salesperson and you continue to engage the prospect / customer the way you always have you run the risk of losing credibility. They do not need you to tell them what they already know and if you see that as your job you are missing a huge opportunity. They are craving a deeper relationship. This is your opportunity to become the Trusted Advisor. What is important now is understanding what they are trying to achieve and helping them achieve it with your products and services.
If you are a high value solutions salesperson then you need to continue to act as the Trusted Advisor and exhibit the traits associated with the role. Hopefully this blog has re-affirmed your commitment to this methodology and motivated you to elevate your sales performance to the next level.
Chief Executive Officer
FileBound Australia Pty Ltd
When thinking about or being tasked with capturing a customer’s detailed requirements, beyond the high-level Business requirements … for me, it’s hard not to immediately draw mental pictures of that well referenced tree swing analogy. For those not familiar with the analogy it simply points out that without proper requirement definition a customer looking for a tree swing could have any of the swings in the illustration delivered to them.
Purposely jumping off the tree swing for a moment… and focusing on software solution marketplace with its vast product range with a plethora of configurations, outcomes and customer experiences, it has never been more important to queue up those powerhouse discovery questions to ensure that you have accurately and clearly understood both the functional and non-functional requirements of your customer. If we do this we avoid delivering the wrong outcome for the client.
A functional requirement typically describes the behaviour (such as automated workflow) or presentation of a configured component that meets the specific needs of the customer, whereas a non-functional requirement describes the systems operation… such as a Web Servers Availability etc.
My Top DO’s and DON’T on Producing Great Requirements Documents
|DO||Have a sound understanding of the customers high-level Business Requirements prior to meeting with them to perform the deeper dive discovery.|
|DON’T||Ask a series of unnecessary/repetitive questions where the information has already been provided in advance. This opens your ‘incompetence account’ with the customer and doesn’t build the necessary rapport or credibility for downstream engagements which are required to deliver success.|
|DO||Schedule a Discovery Session with all applicable stakeholders, communicating in advance a structured approach with an agenda or at a minimum a simple email to highlight discussion points for the Discovery session.|
|DON’T||Avoid the inclusion of the IT Manager and/or Senior IT Representative in your Discovery session.|
|DO||Use the phone wherever possible to help qualify any gaps in understanding of the customer’s requirements. Verbal communications result in far fewer misinterpretations of conveyed information over those which can occur in a series of detailed emails.|
|DON’T||Fill the Requirements document with verbose, non-specific or redundant content (e.g. marketing content) that doesn’t help define or qualify the customers’ requirements for review and approval.|
|DO||Use a very good healthy balance of quality images, screenshots and diagrams to present your clean understanding of the customer requirements in your proposed technology. Microsoft Visio is my go to application of choice.|
|DON’T||Make wild and nonsensical assumptions, when they can be solved with a short call or a qualifying email.|
|DO||Document the specific non-functional requirements for success even if they are requirements for the client to deliver on. IE IT landscape changes needed, additional staff training needed etc|
|DO||Scale the length and depth of Requirements detail with respect to the level of complexity of the solution delivered. See Solution Complexity to Requirement Detail Chart below.|
Using the Correct Weight Approach
Following on from my last ‘DO’ recommendation, Requirement documents should contain the appropriate weight of detail/content to be classed as an ‘efficient document’. Obviously producing an overly wordy document for a small, yet simple project can frustrate many customers as they struggle to digest all of the details. On the flip side unconsciously leaving a lot of important detail out OR left only to verbal references will effectively leave the gate WIDE open for assumptions to be made on all sides. Poorer outcomes are consistently achieved when this lack of detail and specification exists within the documentation.
Solution Complexity to Requirement Detail Chart
Hopefully some of these quick tips will help you produce superior requirements documents for your projects.
Professional Services Director
The Ellby Group (FileBound Australia Pty Ltd and Upflow Pty Ltd)
Our organisation spends a lot of time assisting others to implement Document and Work Management solutions. We have been doing this since 2007 and individually many of us have been doing this for a lot longer with other organisations. We are still surprised at organisational avoidance of implementing change management processes for their teams.
Many years ago systems projects had a very strong technical leaning. Remember using the Software Development Lifecycle (SDLC) to structure long projects to deliver positive organisational outcomes? Projects these days happen a lot quicker (generalisation inserted – we would love your view). This speed is underpinned by advances in technology as well as globalisation driving a world market. We can now configure software to do a lot of things that we used to require software development projects to deliver.
What are the impacts of this faster delivery of organisational outcomes? Here are The Big Four impacts we see;
1. Less structure.
We do not see organisations using Project Managers (PM) and Project Management hygiene as frequently as they used to. This provides less organisational structure which leads to generally poorer outcomes. In our experience having a PM on a project virtually guarantees the project will not fail as well as ensuring the project will deliver at an acceptable time and cost (note the use of acceptable as opposed to budgeted, that could be a single blog in its own right). As a minimum, organisations need to have a responsible executive so that there is a single point of escalation for the technical resources on the project. We would love to see this trend away from formal PM reversed.
2. Less formal requirements.
A significant trend we see is the reduced focus on formal requirements. We often see projects being attempted with no agreed formal requirements. The theory being that the tools can be adjusted so easily that once a solution is live it can be altered as needed. Whilst this may be somewhat true, it does not deal with the various pre-conceived expectations of the stakeholders. Stakeholders are quick to get frustrated and unsupportive of the project if their early expectations are not met. One of the great things about a formal requirements document is the articulation of expectations before any delivery has happened. If there is a gap in the expectations of the solutions delivery team and any of the stakeholders it is highlighted and dealt with long before the project is thrown seriously off track.
3. Lack of a formal change control process
Just having an initial set of requirements is not sufficient. We see projects falter regularly because valid changes to the project are not managed with a controlled process. The beauty of a change control process is the involvement of all stakeholders and management of their expectations throughout the delivery. As with formal requirements, change controls are a vital commercial and legal instrument that can reduce your organisational risks.
4. People aren’t ready
With modern technology we can often implement a really complex solution to an organisational problem in a very small amount of time. Whilst this is great and any technocrats will love the speed and outcome, it give technophobes very little time to adapt to a new work design. We see this happen a lot and often those technophobes will start an internal marketing campaign against the project / changes (interestingly in our experience once the key issues of this group are addressed they can be turned into strong advocates). In our experience the number one reason why projects struggle is the human change element. Of course there is a direct link between this impact and the project management impact described above. Less Project Management hygiene leads to less focus on the core change management principles built into that hygiene. We would encourage anyone currently implementing or considering a technical change project to spend more time considering the human change elements. If you do you will be rewarded for having done so.
Of course there are other factors that can lead to implementation issues – poor technology choice, poor partner choice, external factors, poor resourcing and inadequate skills to name a few. Despite these other risk factors we still see most troubled projects having one or more of The Big Four issues identified above as the root cause of the challenges.
In summary, we suggest that all solution implementation projects have a Project Manager, use a tight requirements recording and change control recording process as well as have a program of change management built into the core deliverables. Implementing hygiene’s to account for The Big Four will seriously improve your chance of implementation success.