neovintage

As a Senior Project Manager at Sparkseed, my job encompasses managing our staff of interns, developing the company's long-term strategy, as well as mentoring any of the Sparkseed funded ventures. Recently, I was asked to mentor one venture, Capital Good Fund (CGF), on what software package to use to implement their back end systems. The team was struggling to determine what package could meet their needs now and into the future. It seemed like a very large task, but I was definitely up for it.

After a few initial emails to get a background on CGF and its mission, I jumped onto a call with one of the founders. One of the very first things that we did was talk about all of the software platforms that they were considering, like MIFOS, Salesforce.com, and Highrise, just to name a few. Almost immediately after identifying all of the software platforms that were up for consideration, the conversation turned into listing all sorts of features that CGF might need.

The key word to point out is "might." Just like with any software development project, I was finding feature creep. We'd discuss one feature and that would certainly lead into another. There were so many things that the team at CGF wanted the software to do that the platform was beginning to look over-complicated.

In terms of providing a solution for CGF, I recommended that we stop talking about technology all together and focus on the core process for the business. In this case, the core business function was the loan process. We then drilled into the loan cycle, how the loans are made, who has authority to make loans, and how the loan gets paid back. At this point, we had a clear understanding of how the business worked and who was involved.

Taking the current staff capabilities into consideration, I was able to recommended a system that had the bare minimum to meet the need of tracking the loan and the various touch points the loan officers would have with their customers.

Side Note: As with any software package, it should be robust enough that if you outgrow the software or want to manipulate it in other ways, the software should let you access the raw data.

Key Lessons learned:

• Always pull back. Ask the question "what operational problem am I trying to solve?"
• Only use as much software is needed to get the job done.

References:

• The Right Mind-set for Managing Information Technology
• Avoiding the Icebergs - Talks about software architecture but still pertinent
• Avoiding the Icebergs #2
• Scope Creep