Specifically, I like this line from "Step 2":
"If a requirement can be only partially met or not addressed by a solution, it is not a core requirement."
Hello?
The truth is: If a solution can not or only partially address a core requirement, it is not a solution.
NEVER change the problem to fit a 'solution' - that's a recipe for disaster.
My $.02,
.jimh
Discussion on:
View:
Show:
Your statement is absolutely right; however, you took the statement " If a reguirement can be only partially met or not addressed by a solution, it is not a core requirement." out of context. Granted after reading your response and the statement byitself I will concede that the wording can be miss leading. If an organization accepts a solution that either does not meet or only partially meets a stated 'core' requirement then the organization miss identified the requirement as a 'core' requirement. The definition of 'core' requirement is one that MUST be covered completely by the solution, no exception. This being the case if the requirement does not need to be meet the total requirement it is not a MUST HAVE requirement and as such sould not be identified as a 'core' requirement. It is desirable for the solution to meet the requirement but it is NOT mandatory.
Thanks for your comment, if the wording miss lead you it could miss lead others.
Thanks for your comment, if the wording miss lead you it could miss lead others.
you mis-read step two... that step is not talking changing the problem, it's talking about identifying whether a "requirement" is a business need that requires a solution [i.e. a "problem"] or if the "problem" is just in the mind of some management type.
Specifically, I liked the line in Step 2:
"If a requirement can be only partially met or not addressed by a solution, it is not a core requirement."
Huh?
The truth is: If a potential solution does not or only partially solves a core requirement, it is not a solution.
NEVER alter the problem to fit a "solution" - that's a recipe for disaster.
My $.02,
.jimh
The statement "NEVER alter the problem to fit a solution - that is a recipe for disaster" is a time proven statement. Step 2 was from the organization's perspective. If an organization identifies a requirement as part of a "core" requirement it is stating that it is a MUST HAVE or NO GO requirement. If a "solution" provider states that the requrement cannot either be completed as stated or not supported at all AND the organization decides to drop or modify the core requirement then it obvilously was not a MUST HAVE or NO GO requirement. No organization is going to stay in business long if it willingly drops a requirement that must be fulfill in order to produce the level of service or quality of product needed to meet the customer's expectations.
This was very informative. I have another twist to this. In my organization, I have both custom built and COTS. I am looking to consolidate... Can I use these steps to determine what method I should continue to use ? I know that consolidation will contribute to a better ROI.
First, I am a firm believer unless you can prove that there will be enough ROI for replacing a system that is meeting your organization’s business needs, do not replace it.
Hopefully your organization has a policy to reassess its solutions periodically to ensure they are still meeting their business needs and goals. When the solution is beginning to reach its limits or no longer meeting your business needs is the time to start planning its replacement. If such a policy does not exist I suggest first investigating if there is a need to replace the system(s) at this time.
If the systems you are planning to consolidate are both supporting the same business processes and meeting your organization’s business needs then theCOTS solution is normally the best route to investigate first.
Often organizations miss all of the indirect costs of supporting a custom solution. Except when a business has some extremely unique ‘must have’ business requirements Ifound that either a complete COTS or ‘customized’ COTS solution provides the best long term ROI.
Hopefully your organization has a policy to reassess its solutions periodically to ensure they are still meeting their business needs and goals. When the solution is beginning to reach its limits or no longer meeting your business needs is the time to start planning its replacement. If such a policy does not exist I suggest first investigating if there is a need to replace the system(s) at this time.
If the systems you are planning to consolidate are both supporting the same business processes and meeting your organization’s business needs then theCOTS solution is normally the best route to investigate first.
Often organizations miss all of the indirect costs of supporting a custom solution. Except when a business has some extremely unique ‘must have’ business requirements Ifound that either a complete COTS or ‘customized’ COTS solution provides the best long term ROI.
The steps suggested have a strong technical influence and apply more to application justification than BUY .vs. BUILD. The best practices in this matter, supported by the most prestigious consulting firms and research groups, indicates that in case of major applications the decision is BUY. Minor applications or extensions of existing is obvious that the decision should be BUILD. BUILD should be considered also in case where we're looking for the transformation of a business process that is different from what the competence is doing and our company would like to generate a competitive advantage (usually we can't find of the shelf solutions).
An internal policy should state: "always consider BUY before BUILD".
An internal policy should state: "always consider BUY before BUILD".
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
