Modern business is a fast paced game and there are always new ways you can discover to improve your operations and output.
One of the easiest and simplest ways to improve the day to day running of your business is to supply your team with better tools.
With the array of modern SaaS products available on the market there are specialized tools for a host of use cases.
We use Close.io for our sales team, Intercom for customer support, and Process Street for our business process management throughout the company.
But if you’re a department within a larger company, or a team within a department, how do you convince top management and finance to sign off on a new software product to boost your team’s performance?
In this article, we’re going to give you a step by step guide of how to make that happen. Including:
- What is a purchase requisition?
- The difficulty of bureaucracy
- 3 important factors to convince finance
- How to write a proposal for a new software purchase requisition
- Create or improve a purchase requisition process
What is a purchase requisition?
A purchase requisition is a document presented internally in an organization as part of the approval process for agreeing the purchase and allowing it to go ahead. It presents information about what a team or department wants to purchase and why.
It should not be confused with a purchase order, which is a document provided once a proposed purchase has already been approved. Purchase orders are sent from the buyer to the supplier as a legally binding document, officially beginning the sale.
Producing a purchase requisition as part of your internal approval processes is seen as best practice because it provides full accountability and transparency for the purchase. You know where all the money is going and who it is going to.
Purchase requisitions are also useful in having a standardized approach to communicating within a large organization. It allows you to highlight what steps you’re taking to improve your team and to demonstrate not only what solution you have chosen, but why you have chosen that particular solution.
As a formal document, this can be referred to in future and stands as a record of your team’s improvement efforts. Short conversations in meetings can often be forgotten whereas a rich and detailed purchase requisition ensures knowledge is not lost in time.
For these reasons, we recommend having a strong purchase requisition process where ideas can be formally presented in depth and also approved. This builds greater communication into your business processes.
This approach is advocated for in further detail in the Harvard Business Review article by Matthew Eatough, CEO of Proxima Procurement, Leaders Can No Longer Afford to Downplay Procurement. Eatough argues that procurement should be driven by business goals and strategy, moving away from the budget oriented numbers-game it has tended towards in large corporate environments.
The difficulty of bureaucracy
One of the specific reasons we chose to write about purchase requisitions is that this often appears as a stumbling block when assessing the agility, innovation, and new-product-adoption in large organizations.
Where a startup can quickly start paying for a new product and deploy it almost overnight, large organizations typically take a long time to make these improvements.
Some large organizations structure themselves to combat this bureaucracy; utilizing task forces or working groups with flexible budgets. But payments still need to be accounted for, and not every workplace is well suited to a grand dynamic restructuring.
According to a study by Gary Hamel and Michele Zanini for the Harvard Business Review, the larger an organization the slower their bureaucratic processes become.
You can see in the image above the timeframe for non-budgeted expenditures in organizations of different sizes.
Hamel and Zanini scored the various organizations involved in the study according to their Bureaucracy Mass Index ratings, with the methodology described briefly here:
For each completed survey, we calculated an overall BMI score by aggregating responses across seven categories of bureaucratic drag: bloat, friction, insularity, disempowerment, risk aversion, inertia, and politicking. We computed an overall BMI based on scale of 20 to 100, based on answers to the first twenty questions of the survey. On our scale, a score of 60 represents a moderate degree of bureaucratic drag, while anything less than 40 indicates a relative absence of bureaucracy.
The results were not surprising, but they were significant:
Of the responses tallied, 64% reported a BMI of more than 70, while less than 1% had a BMI under 40. Not surprisingly, BMI scores were correlated with organizational size. The average BMI for companies with more than 5,000 employees was 75. Of the respondents who reported a BMI of less than 40, three-fourths worked in organizations with fewer than 100 employees. This confirms what most of us have long suspected: large companies suffer from managerial diseconomies of scale.
Which brings us to Process Street and this article in particular.
How can we look to overcome these bureaucratic headaches and improve the internal processes of large organizations?
Well, we can take the example in the graph above and look at an example of non-budgeted expenditure. Say, a new piece of software, for example. And then we can look at where the process problem lies.
The process problem in this case is the purchase requisition process. Which is why we will lay out how to create a solid purchase requisition and present how you can create standardized internal processes to replay these best practices each and every time.
If you want to read more about ways to combat bureaucracy in your business, I suggest you check out one of our recent articles: The Secrets to Making a Bureaucratic Organization Run Like a Startup.
3 important factors to convince finance
Okay, so first off let’s look at the basic things it is useful to have in order to get a purchase approved.
These things are like the scaffolding that holds your plan in place. These might be the non-technical elements to playing the internal politics of a large organization.
And it’s not just me who considers this a factor: internal politics was counted as one of the key factors in determining the HBR’s BMI scores.
This is obviously handy to have.
There are varying levels of buy-in you could achieve. If you’re in an organization which recognizes it needs to improve operations then you’re in a fertile environment for adopting new software and tools for your team.
It may be that you’ve discussed possible needs with members of management before and you have an idea of the kinds of tools they are open to bringing into the company. A lot of this comes down to the culture in your organization.
If you’re trying to bring in a new product for your team, it might be a good idea to bring management into the process at an early stage. Let them know you’re looking at tools to improve performance. Get their input and ask for some recommendations. If they feel involved in the process, they may be more likely to review your proposals generously.
If you’re reading this and thinking “Wait, I am management”, then you should consider whether the company culture you’re creating is one where staff feel confident to approach you to propose improvements; to communicate whether or not there is budget available to improve performance.
This one is difficult to get prior to implementation as employees may not have full experience of the new tool.
However, you can involve your team from the beginning and present the various advantages the new software may bring to their day to day work.
You could run a pilot study in your team in the early stages to gauge how people would feel about certain new tools. Many SaaS products offer trial periods or free pricing plans with reduced feature sets, as Process Street does.
You can take advantage of these services to test the fundamentals of a platform within your team in small experiments. For Process Street, for example, you could build a template for a common recurring process and have a few workers follow that process via the checklist inside the platform.
This allows the team to give you their feedback; giving them a sense of ownership over the adoption process, and you more data to present in your purchase requisition.
If you can show that your team believe a product will be useful and are happy to adopt it, your perceived chances of success at implementing the new software will be higher.
A clear plan for new software
Regardless how much buy-in you have from senior figures or the rest of your team, an organization shouldn’t sign off on a significant purchase of new software without you demonstrating that you have a good reason for getting it and a clear plan for how you will employ it.
Outline the current problem, the benefits of adoption, and the implementation strategy. Perhaps in some kind of clear structured document?
You may have set internal procedures in your company. If so, follow them. But don’t let poor procedures dull your new software’s natural sparkle. Make sure you’re showing off this proposed purchase and all the benefits it can bring.
If the existing procedures don’t give you enough space to demonstrate what you need and why you need it, then you should consider raising that with the necessary people.
So, how do we show a clear plan for this new software? Exactly the reason we’re all here: in a thorough purchase requisition…
How to write a purchase requisition for new software adoption
The key to a purchase requisition is making the business case for the products or services you hope to buy.
This is about understanding your current operations and where there is space for improvement. Then, being able to map the benefits of that improvement in a way which can reasonably be compared with the price – or training time – of the new software.
You may be able to demonstrate that a 10% increase in the output of one of your business processes would lead to a positive return on investment on a monthly basis against the cost of the new software. Once you’ve grounded your reasoning in figures, you can present why this particular software fits into that plan.
With Process Street, for example, you might emphasize its potential for enabling an agile process improvement approach which would make you more likely to achieve the 10% increase in output than other comparable tools. Therefore, not only have you demonstrated that new software may make you more money, but you have grounded it specifically in the choice of software you are requesting funds for.
Here are a series of steps you can use as your structure to guide the way you create the business case for new software adoption to be presented in your purchase requisition.
State the need
Assess current problems or issues that you face.
Are you struggling to keep track of clients as they come through your system? Perhaps different members of the team approach their tasks differently and this hinders optimization efforts? Maybe your database systems are too simple, or not user friendly enough, and this leads to difficulties accessing information?
Provide your analysis of these issues.
Briefly describe why you think this is an important issue within your team. You could talk about the current workarounds your team are employing to tackle this, or you could describe the other impacts this issue is having on broader operations.
Provide team feedback on these issues.
If this is a problem which the whole team is aware of then you could include input from the members on what they feel the impact is, and the kinds of changes they would like to see. This demonstrates team buy-in and should help with motivating your team during initial adoption.
Try to outline the problem in terms of its financial impact.
If possible, it would make for a compelling case if you can estimate lost revenue from the current problem. Or, if you could have a measurable metric to determine the impact.
State the solution
Present the solution simply.
You don’t have to be super specific about the software, but the problem the team is facing and how it could be overcome. If you were looking to convince your company to purchase Process Street, you might tell them that the solution is an improved use of business process management. Through good use of BPM you can standardize your activities and work on optimizing that process – which will lead to improvement across the team.
Back it up with data.
This could be data related to the abstract solution presented, or it could be data specific to the piece of software you want to purchase. If you were pitching Process Street you might include information on BPM stats like:
- Structured onboarding programs result in 58% more new employees staying with a company for more than three years.
- Wodify halved their employee onboarding by switching their BPM software to Process Street.
- Implementing BPM boosts the success rate of your projects by 70% according to Gartner.
Explain simply what the new software does.
This is a chance to overview what this new tool does on a simple level and then begin to explain some of the more complex features. You can then expand on this to paint a clearer picture of what features you will be using and specifically what tasks you will use them for. This helps make it clear what the software is and how it will be employed.
Outline the expected impact on the team.
Make your projections for the potential goals you want to set for the software. It might be that you want to improve a specific process. Or, you may want to increase retention rate via greater customer happiness. If you can outline a clear measure of what constitutes a successful implementation, it is easier to get others on board.
Address the price
Sometimes new software is cheaper than old software
In which case, your job is easy. If you’re using some old clunky enterprise suite which has been around for a while, then it may be possible to save money against your existing systems. As the market around SaaS products has expanded, so too has the range of price points. It’s now possible to get powerful tools at reasonable prices; Process Street, for example, is much more affordable and effective than legacy tools.
Outline clearly what you will get for this price.
Sum up the amount you’re asking for and make it very clear what you are getting in return. You can normally ask the supplier for some of their materials to help you make this point stronger. Lots of modern SaaS products have tiered pricing plans, so you can explain what plan you’re going to purchase and why while outlining briefly what the other plans are. You should may clear how much is to be paid and what the payment schedules are, if applicable.
Outline what other outgoings are no longer needed.
Bringing in software to fix one problem can also make other tasks, software, or planned expansions unnecessary. For example, many companies employ developers to help manage Sharepoint. With a tool like Process Street, you don’t need developers – so your company wouldn’t have to expand in that department in order improve their business process management efforts. Look for these kinds of downstream financial impacts.
Demonstrate what level of effectiveness has to be achieved to offset the financial impact of the problem.
Like described in the introduction to this how-to section, if the new product is to be used on revenue generating activities you may be able to clearly outline what kind of improvements are necessary for the product to pay for itself – and more. Illustrating return on investment at different levels provides a clear picture of what the company will be getting in return for this spending.
Outline the extra added value the software provides
Address the impact on your primary product or services.
This all depends on what kind of software you’re looking to purchase and what its immediate benefits are. For example, a good CRM for customer support might have the primary aim of making customers happier, but may have secondary benefits in helping inform your product evolution via being able to better filter and sort through customer feedback.
Assess the impact on data gathering for further future improvements.
One of the great things about utilizing software in your business is the extra data you can glean on your activities and performance. This data can lead to further improvements and help create cumulative gains. Outline the data gathering benefits, if they exist, as this illustrates the potential for the software to facilitate further benefits in future.
Evaluate the impact on the team.
There could be a host of broader benefits for the team; raised happiness, increased morale, reduced errors, better employee retention, etc. One of our beliefs at Process Street is that you should create processes people enjoy using and processes which make people’s jobs easier. When you do this, you get better process adherence and better output. Look after your team and they’ll look after you.
Explain your training and adoption strategy
Outline how you intend to integrate the product into existing systems.
Here you can describe how you existing systems function and where the new software may fit in. If you have your current business processes mapped out with process diagrams then you could quickly convey the role of the new software by including it in this visual display.
Illustrate how you plan to provide training to the team.
Bringing staff onto a new platform might require a period of training. Assess how much training will be needed and how you will administer the training to the necessary members of the team.
Discuss the impact training and adoption time will have on output.
If the new product is one which will take significant time in training then you should assess and report this potential impact. The same is true of a product which requires a great deal of setting up.
Map out your vision for optimizing the use of the software over time
Outline any other use cases where this software could prove useful.
It might be the case that you’re bringing in this new software to solve a specific problem. However, if the new product proves to be a success, perhaps there would be further use cases within your team’s operations? If so, outline these potential use cases.
Identify other teams which may benefit from your adoption as a pilot test.
In the same vein as above, assess for potential use cases across the company where this software could possibly be deployed. You could offer to prepare a report on the software post-adoption which other departments can use as an advisory document in future.
Identify what long term data can be gathered from the software and the benefits of having this data.
Like you outlined in a previous section, look at what broad benefits could be found by long term data gathering via the new platform.
Create or improve a purchase requisition process
So now you have a step by step guide to creating a purchase requisition and conveying all the information necessary to justify your purchase.
What you can do now, is turn this into a functional standardized process. This way, your organization can create a purchase requisition process which improves interdepartmental communications while ensuring accountability and transparency.
If you were to use Process Street for this template, then a team could simply run this standardized template as a checklist each time they want to submit a purchase request. The manager would fill in the required information in each section and the checklist would act as both a record of this info and as a guide to what info to include.
At the end of the checklist, the manager can submit the request and the relevant stakeholders would be notified.
Simple as that.
How do you manage purchase requisitions in your business? Are you happy with your current approval processes or do you think they need improving? Let us know in the comments below!