You are here:
Entrepreneurial Project Lessons
I recently spoke with Joe Piekarz, President of ActusTech Inc (http://www.timeXchange.net ). I asked him to share his experience with us around the development of his timesheet application. I think there are some project lessons learned in here that many of us could benefit from.
What drove you to build a company around Software as a Service?
In general SaaS, as a software delivery model, provides an opportunity to look beyond just "on-demand" or "pay-as-you-go". It opens up a reevaluation of certain point processes that are typically a portion of an enterprise solution and lets one make certain processes more effective by segregating them as a working partner rather than a component. In our case we were looking at collaborative processes in the delivery of professional services that were inhibited by enterprise architectures, yet were necessary to support one or more enterprise applications. That led us directly to timesheet administration.
As project management has grown more complex over the past decades involving resources from within (employees) and without (contractors), not to mention a growing number of consumers of timesheet produced data (PMO, ERP, BI, HR, Procurement), we saw a problem - redundant timesheet entry. Every organization has their system of collection. Every business unit has theirs. And each worker has to re-key essentially the same data for each instance. Then you add in the collaborative approval processes and you have essentially hit the enterprise wall. Timesheet administration is a point process that supports many other processes in an essential way. The only answer is the security, collaboration, and access that an SaaS delivery model provides.
Opportunity
To think about SaaS
more broadly and create
a business opportunity
Goal
Make a real change
versus "just save
money"
What is special about your initial development project of the product? Was it very iterative in nature? Was there a lot of user feedback during the development process?
We invested 18 months in working with real world users from independent contractors to world-wide consulting organizations. In the process we learned two things - everyone's process is different and everyone's process is the same. That may sound counterintuitive but it's not. There are very few competitive advantages to the way people submit and collect time. The real advantages lie in how the data is purposed. But there can be several subtle differences for different projects. Our take away, and we are always learning more about this, is that user personalization such as role in the project is one thing, but project personalization is just as important. For example, I could be on one project that tracks phases and another that does not. This makes the interface to each project personal. So how do we handle that? By asking natural language questions of the project initiator such as "will there be phases to this project?" "What are the phases?" and so on. This is a world-wide audience of users who more than anything want to simply communicate their time. Project personalization seems to be what our users saw as issue one.
Key Finding
Every project
is different.
The user interface
had to
address that.
What were the greatest challenges you faced during that initial development process and how did you overcome them?
Too often SaaS applications are seen as a "one-size-fits-all" proposition. As alluded to in the prior question, our greatest challenge was getting our development users to talk about their best practices without incorporating either the "one-sizefits-all" or the "ours-is-different" tendency into their thinking. We received much better data when we adjusted our approach from "what do you think a timesheet application should do" to "what do you do?" Then our approach was to make three lists. One list consisted of practices common to everyone such as tracking tasks. The second list consisted of practices that we saw as best practices but which were not universally common. The third list consisted of practices that, for lack of a better term, had to be improved. This again is what led us to natural language project personalization. For some people simplicity is their idea of best practices and for others it's about sophistication. Project personalization was our answer. The lesson learned is that, in the end, it is more about usability and function than anything else.
The second important thing learned is to know where your scope ends. Some users wanted more project management functions. Some wanted more HR functions. Both of which are not our mission. We are a point process. The logical line for a point process to end in an SaaS model is where the Internet is no longer to your advantage. Our mission ends at recording, routing, approval and collection. Beyond that the data is no longer mid-stream it is ready for inclusion in enterprise decision systems. So fight the temptation to do to much or chip away at the applications you want to support.
Key Finding
- Situational lists
helped refine
interface requirements.
Comments
There are no comments for this entry yet.
Commenting is not available in this section entry.