5701 Lonetree Blvd.
Rocklin, CA 95765
|
(916) 920-4730 |
Getting started with us is a simple process. It often involves a few phone calls, a signed NDA, a simple work-for-hire agreement giving you ownership of the work-products and a review of your existing code/database or specifications to create a work-plan.
Call (916) 920.4730 to get started now
Do you have a Web project that is failing, or not performing as well as you hoped when you started? We can help migrate it to a state where it continues to work better and devise a plan to rework and refactor it to the right shape.
Once both your company and ours have entered into a nondisclosure agreement, we will be ready to understand your need in depth. This step can often be completed in one business day or less.
We will hear about your needs and determine if we are right fit or not. This step may require reviewing your system, code and database, etc. Typically, this takes anywhere from few days to weeks depending on the scope of your project.
Once we have had a chance to review your needs, current state of technology artifacts (code, database, documentation, etc.), we will make a proposal to show you how we will go about attending to your needs. Our contract is very simple: you own the code, database, design that you had and will have going forward. Intellectual property (IP) remains with you and if we use existing code/database that we built earlier, we will give you a perpetual license to ease your worries. The key aspect of our contract is that we do not believe in hourly-rates. We only work in retainer model where you commit to a monthly payment based on resources that you use.
Rest easy, the intellectual property (IP) belongs to you. Our service agreement spells out that we are entering a work-for-hire relationship.
Once we are under a retainer contract, we are going to look at all your requirements, wish lists and organize them into manageable feature lists that go from must-haves to good to haves. The must-haves are the features that must be done to either solve current scalability, security or other business-centric issues. The great to haves are ones that you want to have if must-haves are done, and good to have the ones that you want to get done once both must-haves and great to haves are done. These feature lists are organized in version release plans and we will then have defined goals for what is going to be worked on in the next phase of the process.
We will ask you to identify a group of friendly users who won’t mind participating in beta testing new features. Once you have a group created, we are going to create a user blog where they can comment on features, vote on approaches and also report issues via email to our issue tracking system.
We will setup the development environment, assign a development team, setup communication channels (status reporting, mailing lists, internal blogs, etc) and get started with the Must-Haves. You will see progress via our demo servers and get status reports via phone, email and a work blog.
Using QA/QC plan developed in an earlier step, we will perform a set of quality assurance tests and invite the beta users to participate in checking out the new features and ask them for feedback on our product blog.
Once you have reviewed the new work product and provided feedback, we will combine your feedback, user group feedback and our internal QA team recommendations and go back if needed for another iteration of the development. This loop will continue until you are satisfied that the new features are ready for the live environment.
Using replicated live data and contents, we will perform a near realistic live load testing so that we can do further tuning if needed. Once the load tests come back with expected results, we are ready for live deployment.
We will commit a scheduled deployment time based on your system’s least likely time for user interruptions and make the updates live and perform live tests to confirm system availability. We will inform you about the updates and wait for your feedback. If needed, we will roll back changes in case any unforeseen side-effects emerge.
Once the above cycle is completed, we will go for the next set of requirements and continue the same process again and again throughout the life-cycle of the product.
Starting a new project is very similar to starting an existing project with the exceptions discussed below.
A new project does not have an existing code base to review. The Needs Analysis step is replaced with Specification Review. In the specification review process, we dig deep to understand the state of your specification and tell you know what we think of it. Most specifications are incomplete and have reasonably big holes that create project risks.
The hardest part of a new project is to inform the customer that they have big holes in their specification and the best approach is get a version 1.0 plan and iterate through a few times to get full coverage on areas that were missed.
The big holes in your specification might exist because you are “too close” to the project and have assumed a bunch of things that we do not see from a bird’s eye view. So getting your specification in shape itself is a major deliverable for the success of your project. We offer the following choices in such a case: we all work on the specification together or start work with what we understand and iterate through more cycles to create a complete product.
We highly recommend creating a prototype using XHTML/JavaScript and realistic looking data. By showing the prototype to stakeholders, target users, we can learn a great deal about the success and usability of the new product. Most companies want to avoid a prototype to save time but unfortunately most of them pay for it later by reworking work-products as user feedback often identify major usability issues.
We thought you would like to see a cartoon by an unidentified artist showing what typically happens in the consultant-laden software industry with customer projects.
Please click on the cartoon to see a clearer version.