I was working for a client who had bought a software package from one of the ' Market Leading Software Vendor'. The software package promised to deliver out of the box capability for all his software services requirement out of the box. The Software Vendor'. impressed with did an impressive demo of 3 of the services and the client was happy that the product was going to deliver software services in couple of months instead of their development estimates of 12 months to 18 months.The only catch was the 'Software Vendor' told the client that 'most' of the services were ready and 'few' were under development but they would accelerate the development and try to deliver them them ASAP. The client team accepted the 'Software Vendor' verbal assurance and decided to go with the packaged software (#Mistake) .
The client bought the software and engaged my company to implement the package software, with a target to complete the implementation in 4 months as per our assumptions & estimates. As the development started we started getting issue with packaged software code, some of the 'out of the box' services were not ready and other had code quality issue - apparently the code had not been tested.diligently. The 'Software Vendor' told the Client that we should prioritize implementing other services that were ready. The Client was not happy and neither were we as the software implementation team, but Client decided to go ahead and we started implementing the 'new' services which we were told to implement first by the 'Software Vendor'.
After couple of weeks we realized new set of services were not ready as well and so the client setup a meeting with the 'Software Vendor'. In the meeting we and the client decided to review each of the services that 'Software Vendor' had promised were out of the box and we realized that more than 80% services of the package that was sold to our client was only only on paper and 'work in progress' and they would only be available to us after 12 months. The client threatened the 'Software Vendor' to cancel the purchase and walkout but realized that he has invested quite a lot of money in 6 months that we had worked on the 'Software Vendor' packaged software implementation. It would be suicidal for the client IT team to go back to its management and tell them that they had paid high price for a software from 'Market Leader Software Vendor' without performing a due diligence and after 4 months of work realized that the software was not fully ready! There was no option for the Client team to wait till 'Software Vendor' delivered and push the delivery time lines. The revised budget increased to 1.5X and later to 2X and in spite of this the final product that that Client got was full of bugs (which the 'Software Vendor' promised to fix over in future) and it did not implement some of the services that they had 'purchased 'from the .'Market Leader Software Vendor'.
The moral of the story is that the client made some basic mistakes and did not follow the guidelines of buying a 'Out of the box software package'. The client obviously was at fault of finalizing the deal with the vendor before contacting my company for implementation. I was not part of the initial meeting with the client so I can't say if my company representatives had advised the client to verify the readiness of the product he was going to buy and whether we had advised a prototyping phase as we should have done.
Software Packages aren’t always custom fit for your needs. By creating a prototype, the people involved at the earliest stages can better convey their vision for the software and what it’s actually intended to do — and this works better than just describing it through notes.
2. Prototypes Allow for More Customer Involvement
They also allow for that interaction to happen earlier in the design process, when it’s easier to make changes to the software. It’s not uncommon for buyers to ask for one thing, only to realize later on that what they asked for doesn’t work as well in practice as they expected it to… and it’s better for everyone if such problems are found early on. At the same time, prototypes are a good mechanism for explaining what’s technically feasible with the software — and once people know what it can do, they can turn their attention to what they want it to do.
3. Prototypes Provide Users Proper Clarity of Feel for the Software’s Functionality
Related to #2, prototypes serve as a good chance for users to get a feel for what kind of functionality the software will provide once it’s done. Now, at this stage, even the basic functions are far from complete — chances are the software won’t be doing anything more than the simplest tasks. However, that’s still enough to get a good sense of how it’s going to behave when it’s actually done. Without prototyping, the software could end up feeling wrong to the users — and that doesn’t help productivity.
The client bought the software and engaged my company to implement the package software, with a target to complete the implementation in 4 months as per our assumptions & estimates. As the development started we started getting issue with packaged software code, some of the 'out of the box' services were not ready and other had code quality issue - apparently the code had not been tested.diligently. The 'Software Vendor' told the Client that we should prioritize implementing other services that were ready. The Client was not happy and neither were we as the software implementation team, but Client decided to go ahead and we started implementing the 'new' services which we were told to implement first by the 'Software Vendor'.
After couple of weeks we realized new set of services were not ready as well and so the client setup a meeting with the 'Software Vendor'. In the meeting we and the client decided to review each of the services that 'Software Vendor' had promised were out of the box and we realized that more than 80% services of the package that was sold to our client was only only on paper and 'work in progress' and they would only be available to us after 12 months. The client threatened the 'Software Vendor' to cancel the purchase and walkout but realized that he has invested quite a lot of money in 6 months that we had worked on the 'Software Vendor' packaged software implementation. It would be suicidal for the client IT team to go back to its management and tell them that they had paid high price for a software from 'Market Leader Software Vendor' without performing a due diligence and after 4 months of work realized that the software was not fully ready! There was no option for the Client team to wait till 'Software Vendor' delivered and push the delivery time lines. The revised budget increased to 1.5X and later to 2X and in spite of this the final product that that Client got was full of bugs (which the 'Software Vendor' promised to fix over in future) and it did not implement some of the services that they had 'purchased 'from the .'Market Leader Software Vendor'.
The moral of the story is that the client made some basic mistakes and did not follow the guidelines of buying a 'Out of the box software package'. The client obviously was at fault of finalizing the deal with the vendor before contacting my company for implementation. I was not part of the initial meeting with the client so I can't say if my company representatives had advised the client to verify the readiness of the product he was going to buy and whether we had advised a prototyping phase as we should have done.
Why is prototyping important ?
1. Prototypes Help Transmit IntentSoftware Packages aren’t always custom fit for your needs. By creating a prototype, the people involved at the earliest stages can better convey their vision for the software and what it’s actually intended to do — and this works better than just describing it through notes.
2. Prototypes Allow for More Customer Involvement
They also allow for that interaction to happen earlier in the design process, when it’s easier to make changes to the software. It’s not uncommon for buyers to ask for one thing, only to realize later on that what they asked for doesn’t work as well in practice as they expected it to… and it’s better for everyone if such problems are found early on. At the same time, prototypes are a good mechanism for explaining what’s technically feasible with the software — and once people know what it can do, they can turn their attention to what they want it to do.
3. Prototypes Provide Users Proper Clarity of Feel for the Software’s Functionality
Related to #2, prototypes serve as a good chance for users to get a feel for what kind of functionality the software will provide once it’s done. Now, at this stage, even the basic functions are far from complete — chances are the software won’t be doing anything more than the simplest tasks. However, that’s still enough to get a good sense of how it’s going to behave when it’s actually done. Without prototyping, the software could end up feeling wrong to the users — and that doesn’t help productivity.
Here is the right way to invest in a 'Out Of the Box Software Package Product' and this applies to every industry vertical.
- When you buy package software try not to be the 1st implementer of the product is my 1st advice
- Don't get impressed with vendor's demo of few services of packaged software. Demand a complete demo of entire implementation of the software services that you are going to buy deployed on a similar software environment and configuration as yours
- Form a team of technical and domain analyst to explore the demo environment, create a review checklist that covers all critical aspects , review each service in the software package and submit a detailed review report
- Make sure the software package implementation can be customized as per your requirement
- Look at the code of the software and so a sample review of the code quality - 'Software Vendor' should not have a problem in allowing you do review the code you are investing in!
- Finally insist on a prototyping phase and implement few critical services on a replica of your production setup and test the prototype once it is implemented. You can also do a round of performance testing on the prototype
- Make sure the users in your enterprise are involved in all the above stages and they provide their feedback.
- Once above steps are completed with satisfactory result you can go ahead and invest in the 'Software Vendor'
The above checks apply to almost any software small or large that you invest in. I hope sharing my experience will be helpful to enterprise & people buying 'Vendor Software Packages'
