The Discipline of Project Justification - Part 3
Third in a multi-part series
By Tom DeVroy
VP of Sales
I started this series discussing some of the steps I’d recommend to a project team when trying to justify a project to management. The second part of the series dealt with the definition of the business case. In this post I’d like to discuss a solution scenario, which is a situation where you have management understanding that there is problem, perhaps they have painted a vision or made a vision statement, and now they’d like to hear your ideas for potential solutions. Not that they are looking for a vendor recommendation or the definition of what the internal costs might be, but are simply interested in hearing more about their options in a way the demonstrates you understand what is trying to be achieved.
This requires some research and often times a good deal of work. You have already spent a long time thinking about what the business problems are that you want to fix. This could be inefficiency in your operation, dual data entry, lack of visibility to service levels during a service process, missed revenue opportunities, or whatever the case may be. Understanding your business problems that need to be fixed should drive a whole new set of business requirements.
What’s the Current State of your Company?
These requirements reflect the necessity of your specific business, as well as those requirements necessary to address your future model. Consultants refer to this as current and future state. It would make sense that most people know their current state but I frequently find that this isn’t the case. Often when we ask prospects about their current business process we tend to get more questions, blank stares, and referrals to other departments or individuals. It is very hard to derive the benefit of a new automation project when you can’t determine the impact on your current business.
Take the time to define your current operating model. If time or resource demands are too great to perform an adequate analysis internally, hire a consultant - they are experts at performing these assessments. This, however, is a task best performed internally because it requires a good deal of interdepartmental cooperation and communication.
The Present will define the Future
When completed you need to take the documentation to determine the future state of your company (the state it will be in after the problems are fixed). This future state ought to align with the vision of management. Once again, if you have a problem thinking outside the box, hire some external industry expertise, or use the change process to force this new model of thinking. It’s ideal to do this work before you start a solution search but it’s not always practical. Do the best you can to at least identify what it is in your current state that you want to change or fix. Between the current state and the future state this should drive your requirements.
Draft your requirements against those processes in the current model that you want and need to bring forward, as well as those requirements necessary to meet your future state. A good example would be a company that closes out their service calls on paper. This causes delays in billing, disputed invoices, and extends their AR days outstanding. To remedy the problem they would like to automate this function through mobile automation for their field people. After this is clearly articulated, management will want to know their options.
Make Sure that Management is Onboard
Speaking of management, get approval and sign-off along the way. Have them review the current state documents and have them approve the drafted changes in the future state. They should be well aware of these changes seeing that they are the ones that ought to be driving the changes.
The research in the solution definition should include the technology choices, different vendors, preliminary budgets, and so forth. Once again, get some management approval on the technology and the vendor alternatives. Managers may have strong preferences to particular technologies - or they may not care as long as the functionality meets the needs of the business. Whatever their opinion, it’s always better to determine this up front.
Don’t Blow it on an Unrealistic Budget
There’s nothing worse than spending a long time on a project only to find out that there is absolutely no money to fund it. So it’s important to make sure that your budget estimates are realistic. Finally, get your potential vendor alternatives approved in advance. Managers and executives may have had past dealings with a vendor that drives their preferences. Once again, better to understand these preferences up front.
I find that the selling process for Metrix is often a validation process for our prospects. They go through a buying process to validate a decision that was tentatively made prior to vendor evaluation. It pays to do as much up front research as possible, getting buy-in and approval along the way.
In the next post I’ll discuss how you might want to define project assumptions and potential risks, as well as rewards.
View Part 1 Here
View Part 2 Here
View Part 4 Here
View Part 5 Here
By Tom DeVroy
VP of Sales
I started this series discussing some of the steps I’d recommend to a project team when trying to justify a project to management. The second part of the series dealt with the definition of the business case. In this post I’d like to discuss a solution scenario, which is a situation where you have management understanding that there is problem, perhaps they have painted a vision or made a vision statement, and now they’d like to hear your ideas for potential solutions. Not that they are looking for a vendor recommendation or the definition of what the internal costs might be, but are simply interested in hearing more about their options in a way the demonstrates you understand what is trying to be achieved.
This requires some research and often times a good deal of work. You have already spent a long time thinking about what the business problems are that you want to fix. This could be inefficiency in your operation, dual data entry, lack of visibility to service levels during a service process, missed revenue opportunities, or whatever the case may be. Understanding your business problems that need to be fixed should drive a whole new set of business requirements.
What’s the Current State of your Company?
These requirements reflect the necessity of your specific business, as well as those requirements necessary to address your future model. Consultants refer to this as current and future state. It would make sense that most people know their current state but I frequently find that this isn’t the case. Often when we ask prospects about their current business process we tend to get more questions, blank stares, and referrals to other departments or individuals. It is very hard to derive the benefit of a new automation project when you can’t determine the impact on your current business.
Take the time to define your current operating model. If time or resource demands are too great to perform an adequate analysis internally, hire a consultant - they are experts at performing these assessments. This, however, is a task best performed internally because it requires a good deal of interdepartmental cooperation and communication.
The Present will define the Future
When completed you need to take the documentation to determine the future state of your company (the state it will be in after the problems are fixed). This future state ought to align with the vision of management. Once again, if you have a problem thinking outside the box, hire some external industry expertise, or use the change process to force this new model of thinking. It’s ideal to do this work before you start a solution search but it’s not always practical. Do the best you can to at least identify what it is in your current state that you want to change or fix. Between the current state and the future state this should drive your requirements.
Draft your requirements against those processes in the current model that you want and need to bring forward, as well as those requirements necessary to meet your future state. A good example would be a company that closes out their service calls on paper. This causes delays in billing, disputed invoices, and extends their AR days outstanding. To remedy the problem they would like to automate this function through mobile automation for their field people. After this is clearly articulated, management will want to know their options.
Make Sure that Management is Onboard
Speaking of management, get approval and sign-off along the way. Have them review the current state documents and have them approve the drafted changes in the future state. They should be well aware of these changes seeing that they are the ones that ought to be driving the changes.
The research in the solution definition should include the technology choices, different vendors, preliminary budgets, and so forth. Once again, get some management approval on the technology and the vendor alternatives. Managers may have strong preferences to particular technologies - or they may not care as long as the functionality meets the needs of the business. Whatever their opinion, it’s always better to determine this up front.
Don’t Blow it on an Unrealistic Budget
There’s nothing worse than spending a long time on a project only to find out that there is absolutely no money to fund it. So it’s important to make sure that your budget estimates are realistic. Finally, get your potential vendor alternatives approved in advance. Managers and executives may have had past dealings with a vendor that drives their preferences. Once again, better to understand these preferences up front.
I find that the selling process for Metrix is often a validation process for our prospects. They go through a buying process to validate a decision that was tentatively made prior to vendor evaluation. It pays to do as much up front research as possible, getting buy-in and approval along the way.
In the next post I’ll discuss how you might want to define project assumptions and potential risks, as well as rewards.
View Part 1 Here
View Part 2 Here
View Part 4 Here
View Part 5 Here
Get the Metrix Blog Feed
Metrix Blog Home
2 Comments:
Tom: You are making a decision that is very simple and making it very complicated. The decision matrix rolls like this: Is developing your software in house your core competency? If no, find a vendor that can do it better. Now, this relationship must be a WIN-WIN. Justifying the project is very easy. You are taking fixed costs and converting them to variable costs---this is a good thing. Now, from an ROA/ROI perspective, discount the future cash flows (I like 20%)and determine if your this rate is greater than the aforementioned hurdle rate. It really comes down to FTEs. If Metrix can demonstrate real savings here, then it's a no brainer.
To Anonymous: I would agree with most of your points. I suppose the issue to debate is who is making the decision and from what frame of reference. If you are senior manager and have the authority to decide on a homegrown versus vendor decision then by all means cut through the politics and get on with it. If you are a delegated project team, then bring a little discipline to the project. It also depends upon the size of the organization we are dealing with. Small organizations tend to be quick and nimble, large organizations not so. As for your ROI comments you are a little ahead of me on my posts. FTE is an interesting variable that I plan to address in future posts. Sometimes this is the driver, but not always. I appreciate you taking the time to comment.
Post a Comment
Links to this post:
Create a Link
<< Home