Minimum Viable Product for Enterprise Customers

March 2, 2014

You need to iterate fast to release, but not with a  poor quality product that does not address at least basic needs in an Enterprise situation

Firstly, it takes longer to identify test customers in a corporate setting vs a consumer website and enterprise customers have a higher expectation of software.  More importantly, your channel can make or break your product and with limited testing resources you don’t want to jeopardize the opportunity.

The right balance needs to be identified, with the right minimal features built well and working solidly.

Advertisements

Steps to moving E-Discovery to the Cloud – Making it work

September 26, 2013

See http://www.information-management.com/news/10-things-to-know-before-moving-e-discovery-to-the-cloud-10024898-1.html?zkPrintable=1&nopagination=1

for proposed steps.  The steps might appear logical, but involving all stakeholders in committee meetings as a first step is a sure way to bring the project to a screeching halt.

I would reverse the steps as follows to be a more agile approach to implementation of moving E-discovery to the cloud

1 – Evaluate the e-discovery platform first and the cloud options second – This is to ensure you have the right e-discovery platform

2 – Assess potential – and realistic – risks associated with security, data privacy and data loss prevention – This is homework to ensure you are prepared to answer questions that will surely come up in regards to data security.  What you will find in most cases is that the solution is going to be more secure.

 3 – Learn the differences between public and private clouds – This is part of security assessment and this step is to reach a decision on which cloud to utilize for your needs.

4 – Run a pilot on a small project before moving to larger, mission-critical matters – this puts the project in action mode

5 – Benchmark your existing e-discovery processes including data upload, processing, review and export. – This is necessary to arm you with information as you sell the move to the cloud.  Once again, you will find that processes in general work faster than behind the firewall if implemented correctly.

6 – Document and define areas of potential cost savings – This is necessary step and required to make the case for transition to the cloud

7 – Leverage the success or adoption of other SaaS solutions in the organization to lessen resistance – This is the start of the sales pitch.  We have done it before & we are now going to adopt similar approach for E-Discovery

8 -Actively involve all stakeholders across multiple departments – Now get into a meeting with all parties. At this stage you are armed with success on a small project, have information on data security, benchmarks and cost to face the “committee”

9 – Develop an implementation plan, including an internal communication strategy – You have the OK, now go Execute!!

10 – Understand you are still the ultimate custodian of all electronically stored information.


Lessons learnt in IT Offshore Management for Startups

April 12, 2013

No matter how brilliant your new software  may be, it’s doomed if you can’t figure out how to make it efficiently, consistently and economically.

Starts up engage offshore teams due to lower costs & ease of getting teams engaged with tools like e-lance.  However, Creating brilliant and functional software is more difficult than ever due to a lack of offshore team  management skills . My experience at managing offshore IT organizations has taught me some important lessons about software design and production that, if heeded by software startups, provide an opportunity to bring innovative products to market without suffering setbacks – or even failure – from preventable mistakes.

1 – Get Inside the Software Shop

I’ve met too many people in this game who spend several weeks researching software vendors, in some cases even identify top talent, hand over project details  and get on the phone once a week for a status report.  This leads to enormous problems at launch time – Badly designed product and a mismatch between expectation & software delivered.

Speak on a daily basis.  Speak directly to the individual developers, testers, Business Analysts and not just the project managers.  You’ll be amazed at what you learn about the software development process and your software development partner.  Seemingly small pieces of information from these conversations can later help you refine product design or even clue you in to larger issues with the partner’s management.

 

2 – Build Prototypes Closer to home

You often get what you pay for in this realm, so it isn’t where you want to pinch pennies. Use the prototyping phase to refine, refine and refine some more. That way, when it comes time to spend money on software development,   you only have to do it once.

The added benefit of prototyping close to home is that you can iterate faster.  Expedited turnaround times accelerate overall development cycles, and in turn, reduce development costs. Rapid development also gets your product to market faster than the competition!

 

3 – The job does not end after launch

Once you launch (congrats!), resist the temptation to sit back and watch it all happen. To the contrary, this is when real development begins.  Ensure you have left a good budget for further development.    I have seen far too many software startups spend money pre-launch, leaving no allotment for development activities once they have received feedback from real users.  This is where prototyping also helps.  Continue to meet with offshore partner on daily basis.

 

 


Software Project Success – Prototype First

November 13, 2012

As I review the successful (defined as on-time and within budget)  & unsuccessful projects that I have led over the past 10 years, a common thread has been that successful projects had at least 80% complete prototype prior to start of any development work.  This is spread across both Agile and waterfall methodologies.

The prototype allowed the Business Analysts to “touch” the product and better visualize & communicate what they expect of the product.

To get a project kicked off, start with a UI Developer and a Business Analyst.  Refine requirements till you are 80% complete and then bring Software Architects.

This may seem contrary to several Agile approaches, but in my perspective it is a modified Agile approach that has worked for my teams.  The agility is divided into 2 phases – Agile requirement gathering (with UI developer & business Analyst) and then move to Agile software development.

I have also noticed that bringing software developers into the process prior to the product vision being ready,  tends to compromise the product vision and it is best to involve them in architecture & development once the vision is clear.