Common Problems
- Effort becomes focused on specific details too early in the requirement gathering process. Eventually, the prototypical, "I can't see the forest for the trees," scenario occurs.
- Mysteriously, the to-be process looks eerily similar to the as-is process in terms of the different steps that are undertaken. Problems inherent in the as-is solution may still exist in the newer one. I can't tell you how many times I've encountered this problem. People are generally resistant to change. There is comfort in the familiar. Sometimes, people just don't know a better way to do something.
- We end up spending excessive time defining a to-be process that restricts our thinking and may not be used. In short, we are designing a solution.
To be or not to be?
Think of it from the perspective of a company trying to come up with a solution to a problem they are facing. Ultimately, there are a few different avenues: buy, leverage (what you already have), extend (enhance what you have) or build (from scratch). If I use a complicated process to evaluate vendor products, it is very unlikely that I will find one that meets my requirements to a tee. Instead, I may conclude that, "We are unique and as such no vendor product suits our needs. Thus, we must build a solution."Think about how many companies you've encountered in your life that were truly doing unique things and compare this to the number of companies that thought they were doing unique things. A rose is a rose is a rose.
To me, this is the worst outcome. You have already, determined your path without realizing it (you have, in effect, not been solution agnostic.)
In Conclusion
- You may choose a less optimal solution path (e.g., build something that can be purchased.)
- You have not used your time effectively.
These things represent inefficient use of time, resources and money. And the ultimate solution may not be as efficient as it could have been.
No comments:
Post a Comment
Thanks for taking the time to comment or provide feedback!