Archive for September 2009
I was having a conversation with an enterprise software vendor. He was mentioning that the biggest challenge that he faces is that he is not able to increase the adoption levels of his software and it is costing him dearly. I just casually mentioned to him that the usabiilty of his software should be as simple as using a desktop productivity tool. I am not sure if this got him thinking, but it certainly got me thinking deep about how we do this at Ivesia.
I just broke them down into user adoption challenges and the solution that Ivesia offers. I’ve just reproduced them here.
- Enterprises are failing to make best use of the software that they already possess
- User adoption will remain a premium without ease-of-use
Though this has been a much debated topic for the last decade or so, it still remains a challenge for the enterprises. They don’t get to decide whether to buy or to build as each has its own pros and cons. In this post, I have covered this dilemma and try to offer an alternate option as well.
When should I buy software?
- Software offers a good fit for majority of your requirements
- Software can be customized to meet the remaining requirements; else the remaining requirements can be modified for the software
- License cost of the software is not very high and offers fairly decent ROI
- Maintenance contract costs don’t run very high year-on-year
- If you want the software implemented yesterday
These justify the option of buying the software.
When should I build software?
I have earlier written in Part I about the challenges of a testing organization. We also touched upon shortly about the solution, which is a Testing Centre of Excellence (TCoE). In this post, let us see in detail what exactly a Testing Centre of Excellence is.
In a traditional model of testing, members of separate project teams do the verification and validation in the software development lifecycle. These teams need to be trained for each project and is not an efficient process. Additionally, they cannot ensure consistent quality across a business unit as they are focused on specific projects that have varying levels of budget allocation.
Assume that there are 6 projects that are carried out in a business unit; each project will have phases like requirements, design, development, testing, deployment and support. In a TCoE, testing as a function is kept as a shared service across all the 6 projects that provide unbiased verification and validation.