Progress with Plans - update for April 1997 From: Mark Rauterkus, firstname.lastname@example.org Here is a splash of news to catch everyone up to speed on recent activities. Sorry for the lengthy period of silence, but it was necessary to get a few internal things back in order before moving forward. Some quiet strides on many fronts have occured in the past number of months. In the near future, you and the other insiders are going to be able to take a gander at the re-launched public WWW site and the private plans. These notes do not cover the core parts of the actual business, but rather provide you some insight into our planing progress and recent activities.
At this time, nobody needs to make any promises. Hopefully you and the others are going to say, "Sure - keep me under consideration."
As always, thanks for the time and consideration. If you'd like to be removed from future correspondence and updates, or if you would like to widen or increase this communication to you and others close to your operation, please let me know.
Update News with New Partner - MDI.NET A deal is about to be constructed with a local firm, MDI.NET. This established Pittsburgh firm is an ISP with a T1 line and a SUN reseller status. MDI is going to help with the SportSurf.Net efforts by providing in-kind services on a long-term basis. This new "partner" is considered a final cog that is going to allow these projects to advance to the next level. Timeline Consturction Phases, goals and milestones with specific time-lines of implementation are now being charted for the future. Next steps include:
a re-write of my business plans. The plans will appear on a newly constructed private WWW site. The plans are going to set the stage for a new corporation with investor financing. Angel investors are needed to secure trademarks and retainers, but we quickly seek Venture capital funding (>$2 million) - to come in stages of access. a reconstruction of the public WWW site (http://www.sportsurf.net). The site is going to include offers for sales/services in both a freeware and cash-producing manner. Many chat rooms, forums, mailing lists, and book-content things and such are going to be free. Our product line-up for the near-term is going to be catered to the sports business marketplace and start with small, specialized items -- not comprehensive bundles. Some of the short-term goals include: The sale of the book publishing business. Opening the public WWW site with >10,000 pages of mostly free goodies (forums, chats, link pages, etc.) Promotions on the net to get visitor count to more than 1,000 per day and 30,000 per month. Opening of a "Proving Ground" section The Proving Ground is going to be the mechanisim for creating alliances with developers/resellers/consultants. The Proving Ground activities include satellite services and value-added tech-support. This more formalized line-up of service offerings should provide for the short-term common ground between the smaller, cutting-edge software developers and this organization. Plus the Proving Ground activities are going to expand into future resale operations with the pending bundles. Bundles of Tomorrow The future bundles are going to be called: Sandlot Servers and Stadium Servers. These will be turn-key server bundles (to include software, hardware, customization, integration with the headquarters, leasing options, extra support meetings, value-added content offerings) are to be marketed to the 6,000 sports magazine publishers in North America.
Sandlot and Stadium Server packages provide server platform options for the customers. The servers are going to be built for the following operating systems:
Macintosh, NT, Lynix and SUN Without Investor Strategy At this time, there isn't any "investor strategy." However, I am starting to craft a draft INPUT strategy. Without the legally formed business organization, and paperwork for the new one is expected to be filed in the late spring of summer of 1997, talk of "investors" is premature. Instead, these ideas only relate to Input Contributors. The A-B-Cs of Input... Begin with "Angels" The finance input strategy is soon to turn to the discover and solicitaion of much needed "Angels." The input from Angles can fund the next phases. Early finance requirements project a need of aproximately $50,000. The Angel-level-finance amount, given the scope of these plans, is modest. A great distance has already been traveled through our collective carrees and with these associated plans and prototyes. Great cost reductions are in place from lots of sources including family. Present day overhead is low, and nearly all of the tools we've been utilizing are getting crafted to fabulous levels of power and sophistication.
Furthermore, the pending sale of the SSS book business could yeild additional income and turn back the tide on some debt issues. The prospective income from the transfer of the SSS book business is a tenious situation however and not to be counted as a liquid asset.
The goal of the Angel finances is to allow for the growth of the on-line activities to a self-sustaining level while allowing for the completion of the business plans. Angels are needed before any serious audience with the Venture Capital crowd can occur with confidence. For instance, angel income would allow for fees associated with obtaining trade-marks for program-specific names, business plans re-writes, law-team retainers, and expert accounting consulting.
After Angels After the Angels come the Venture Capital investors. This progression from one to the other can occur quickly. The pending pitch to Venture Capital people includes two main points:
almost all the development is already COMPLETED. The full extent of the service offerings can be taken into the marketplace in a matter of weeks -- almost everything has proven to work!
Today's venture capital crowd is NOT interested in funding long-term internet research and development efforts. Funding for Sport Surf Net is a sure thing as all the computer systems are proven to work as advertised. The venture funding is needed to enter into the marketplace and handle the resulting demands.
If there are incomplete elements of the project lurking, they can be completed in one quarter and can be tested just before sales get underway.
Very low RISK. Only small amounts of up-front cash is needed for early risks. The first stage of expenditures comes as these plans and finished prototypes head to focus group research stages.
A respected local focus group company that works with advertising agencies is ready to help. The fee is about $100,000. Focus group research is a wise investment.
If these products and services should pass through the rigors of independent demographic-type studies, the the organization is going to need additional funds for marketing (advertising, seminars). The advertising/marketing campaign for dealers and consumers for the new product roll-outs could cost $500,000 or more.
Both of those investments (focus groups & advertising) are "short-term investments" and can offer a quick returns.
Modest Infrastructure Costs Some venture capital money is going to be needed for infrastructure support. The organization will need back-ups, engineer staff, demo units, telephone operators, mailings to magazine publishers, meeting reservations. As far as the net transactions are concerned, today's access capicity is already strong. The full product launch is going to require availble cash for overhead, plus there is the matter of acquiring or retaining our key partners -- with and without stock equity.
Jack, I'm counting on you to be the one who is going to be able to provide the Lynix server packages.
Furthermore, this is a pipe dream at this stage now, I'd like to be able to have a section in the pending business plan that is going to deal directly with the acquisition of your services -- either in a retain basis or more -- so that you can be fully-funded and a part of our total mission. I don't think these venture capital people are going to be in the mind set to invest money into this project unless we have a good amount of control/ownership and assurances that things are going to get done/happen at a top priority. Obviously, for this type of control to happen, $ needs to come into play first. Plus, my present business and capabilities are not nearly big enough to engage the type of market-cap potential that is going to lure the interest of venture capital types. We need to have proven assets that are worth the investment dollars or else those guys just are not interested. I feel that my team of cutting-edge developer buddies -- all small guys when you look at the likes of Fortune 500 companies -- could band together in some manner and be able to command a sizable equity investment.
To make this work, we're going to need to go on some type of "acquisitions" spree and be able to circle our wagons and say -- hey -- for $10-million you get A, B, C, D and so forth all the way to L,M,N,O, P -- or Z. But, as you might guess, the hand-holding is going to get to be a chore - and we are going to need to have everything pulled together in tight, neat packages for this to succeed.
So, you can see how it is of prime importance that you work these days with this in-mind for the future. All the players will have to have an eye toward this "summary day" and would be able to present some valuable plug-and-play business facts and figures for inserting into the master plan. I'll create the overall master plan but include parts of your data. I'd even say a 1-page executive summary would be too long for the Venture Capital Crowd to digest.
Then comes the matter of $ amounts. Part of this could be with "funny money" in the form of equity, stock options, etc. But, it will also need to boil down to knowing the following:
1. How much is your present business worth in real money at that point in time?
2. How much value does your contributions bring to the overall value of the whole business?
3. How much (on the low, medium, and high side) would you be willing transfer in your venture's ownership -- given that you are still going to play a most valuable role in the continuation of your efforts.
4. How much investment is really needed to take your products and services to the next level of profitability for the short-term and long-term.
5. How much of your day-to-day challenges, work-load and management can be better optimized with OUTSOURCING to the Headquarters staff - res
ulting in increased productivity for all? ---- As to the EASY-Serv side of things: Here is what I'm thinking.
It is going to be great to be able to go to any magazine publisher and say, you need to buy into either our Stadium Server ($50,000) or Sandlot Server $15,000. You'll get everything you need, plus full integration into our headquarter's site databases, traffic, resources. And, our server line-up comes with many different flavors: Macintosh, NT, Lynix, SUN -- with many options. On the low end, a publisher can just rent rooms on our site. So, the Lynix solution is more of a middle-line-up product. The Easy-Serve gives great bang for the buck. Plus, it allows for local dial-up support for the magazine staff out of the office. Heck it uses the #1 server in the world wide web - Apache. This is important to our efforts.
- 1 Construction of Services Occurs in a Formalized Manner
- 2 The whole issue of demonstration and pre-flight understanding is an important first step:
- 3 The whole issue of testing services is an important second step:
- 4 The whole issue of acceptance and testing is an important third step:
- 5 The whole issue of TEST PLANS is an important fifth step:
Construction of Services Occurs in a Formalized Manner[edit | edit source]
The Scoop on Sampling[edit | edit source]
You can agree to purchase internet services that are a part of The Sports Dorm. However this service purchase transaction isn't conducted as if you were in an ice cream store where you can sample without buying. There are free demos and all the documents are free for your examination, but getting a customized service built for your organization isn't free. Nonetheless, our samples don't cost much.
The grey area to me usually involves remaining competetive. A certain share of this work is relatively small projects for relatively small businsesses. Potential client are not told that the costs for our submitions of proposal cost hundreds or thousands of dollars. Most of these prospective business would run from proposals that include upfront payments. Some might move on to the next consultant, but most would not do anything. In all of these buying situations, everyone needs to notice the big disclaimer at the top of these proposals. The disclaimer says that "this document is just for use with communication between prospective customers and customers of The Sports Surf Net and that use of these documents for any other reason (i.e., as a project spec internally or externally) and the charges for these uses cost a minimum of $10-thousand dollars payable immediatly and enforcable under Pennsylvalia law.
Joint Ownership Extends Everywhere[edit | edit source]
The founders and consultants who bring you The Sports Dorm believe that the services at this site must be viewed as a joint sense of ownership. The ultimate success of the project must be shared by the developers and service hosts as well as the client and content providers. Ownership is shared among the dorm administators (headquarter's staff), the customization developer for that particular service (dorm consultants) and the organization who is going to be the prime sponsor and content provider in that service. Furthermore, ownership lines can be widened even further when the end-users who are expected to be the clients and visitors to the site. Often these visitors may experience a sense of ownership too. The visitors to these services might be board members, boosters and captains on the various teams and sports organizations. They should feel like the owners. Everyone needs to feel empowered by the status of ownership.
The liklihood of a worthwhile outcome is as much the client's concern as it is the concern of the headquarter's staff. Everyone need to have their feet in the fire just as much as the service providers. Several elements bring structure to this set of services that help create this joint ownership concept.
Process[edit | edit source]
- Test Cases
- Acceptance Testing
- Testing Plans
- Numbered Dot Documents
- Migration of Services To Live Site
The whole issue of demonstration and pre-flight understanding is an important first step:[edit | edit source]
All the services that are delivered here are fully documented and explained with tutorials. All of the documents are visible on the site and they all need to be read, studied and shared among your group before any order is submitted. It might take your board two month or two years before the final approval is obtained before services can be launched. That is fine with us as we'll be here waiting for you. It does not help matters to submit a "pending order" in advance of the final order.
Board members leave, coaches change jobs, captains graduate and new people may not have the experience necessary to run an on-going service. We want your people to fully understand the services, the possible options and the capabilities. You need to point your poeple to our help desks and have them pick-up the manals and guidelines as often as they want.
Some of the guidelines are going to change over time. In all instances, the lastest edition if the most valid and easiest to understand.
When any pre-sale tech-support message arrives, the first response from the service provider is often an auto-responder message that confirms that you, the person asking the question, has access to and has recently reviewed the demonstration documentation. Only after our tech-support sales team has confirmation that the base-line tutorial is understood, then is a human going to respond to email questions.
The whole issue of testing services is an important second step:[edit | edit source]
All the services that are a part of this offering have fully-operational testing suites. Take a test-drive in the flight simulators before you go into the "real" rooms. The interaction of the buttons, how to make your input seen, and what that input is going to look like are all real concerns. Novice and experienced users can jump into the test-drive rooms and submit a message saying "blah-blah-blah." Then you can see what is going to happen in these virtual environments. Use the testing simluation rooms to get the hang of what is going to happen when you make certain inputs.
Rookies need to try out the services before they jump on-line in the real rooms. A bogus message can be broadcasted over the net for thousands of people to see if you goof up in some of the biggest services.
The whole issue of acceptance and testing is an important third step:[edit | edit source]
As you make the purchase of a new service, say a new chat room for your sports team, there is a formal stage called "acceptance and testing." Your service gets constructed and put onto the internet in a private location for a period of time as you and your whole team gets final accpetance and approval. This stage is where you can make changes and pay for customization of the services at a fraction of the cost of later change charges and embarassements.
The staging area has limited capacity and limited tolerance for approval. Your organization is expected to make a move to final approval in a reasonable time-period or else the project gets deleted and the initial downpayment lost.
Paying to get a service put on-line and later deleted might make good sense to your organization so it can further sell the concepts to a wider board and get additional services in the future.
If you make a number of mistakes, say not spelling the coach's name properly, and want to start over on your design and template construction, that is ok. In many instances it makes good sense to re-compile a whole new area rather than have a consultant tweek with your conent and meet with consultant charges. A consultant works with you to gain final approval and then pulls the plug on the staging area and ships your site to the "live dorm area." This transition can take a bit of time (2-weeks or so).
As clients sign-up for services all the necessary forms and information is gathered as to the requirements so the service is specified in the application fully. The spec goes into a formal document will all points broken down to an atomic level and fully numbered in "dot" notation. The client is free to stop the specification process at any point.
This time is billed at an hourly rate for customization changes.
The services are built based upon the job's specification.
The whole issue of TEST PLANS is an important fifth step:[edit | edit source]
One of the form exercises that is part of the process is the client produced Test Plan that establishes acceptance. Our clients understand that in any non-trivial application it's the client who understands the problem space well enough to come up with test cases that will truly establish correctness. If they need help creating the test plan we'll do that, again billed at an hourly rate.
Each test in the Test Plan _must_ be directly linked to an item in the Specification. i.e.- if they want to test for the order in which items appear in a popup list, then there must be an item in the spec which indicates in what order they are to appear .
When an application passes all tests as contained in the Test Plan acceptance is deemed complete.
If the client wants to add something to the Test Plan that is not covered in the spec, then we're back into the requirements phase and the clock is turned on while we get it all worked out and fully integrated into the specification document. If the additions require a change to the work to be performed we generate a Change Order that is added to the original bid amount. This change process can take place at any time, including the middle of acceptance testing, but it _cannot_ be circumented.
As an example from an actual document for a recent project. -[edit | edit source]
18.104.22.168.2.2.5 The pop up list of choices for FOB location shall be sorted in ascending order on the name of the location. 22.214.171.124.126.96.36.199 Cities with names beginning is 'St.' (St. Louis, etc.) shall be sorted into order as if the name were spelled out with the work 'Saint'. 188.8.131.52.184.108.40.206 Cities with names beginnning with an article ('the', 'a', etc.) will be listed without consideration of the first word. 220.127.116.11.18.104.22.168 Names of cities in languages other than English shall be listed exactly as spelled.
The three clarifications on St., cities beginning with..., and foreign city names were added after the document was complete and resulted in a substantial change order added to the original bid.
Most of our work is with organizations that have limited experience in custom software development. With clients who lack this experience there is often an "education" process required.
Alternative for Non-Reading Ownership[edit | edit source]
The remedy for the clients who do not want to go the expense of personal time to read the totally comprehensive specifications, manual, demos and such. Following along in the spec process can take double or triple the time for setting-up a project.
General specifications for services can be quickly resolved in an email or two and the whole process can move along very quickly -- at a cost of ten-times the standard rate.
If you are one of the clients who expect changes to features in the guise of bug fixes, if you want to charge ahead without attention to detail, and if you want to create your own methods of approvals, then we might be able to accomidate you and make certain speedy measures available at nomal costs x 10 rate for installation and $100 per call on tech support.
Bugs or Defect[edit | edit source]
A defect in the code is that is implemented is usually referred to as a "bug". If bugs are found in testing, the bug is squashed at no charge. If a bug is found during the acceptance period depending on the nature of the application, the bug gets fixed at regular hourly rates.
The clients write the Test Plan, and the clients can write their own test plans as strictly as they please. If the clients didn't write a Test Plan that found the defect, then the defect is in the Test Plan as well as in the code that has been implementated.
Given that, the Test Plan should cover the points that are of critical importance to the client. When less critical defects are discovered it may be the client's choice to live with them, just as they chose to live with defects in any commercial software they purchase.
More often, defects are found in the specification; either a point is described incorrectly or is missing altogether. Those are jointly the responsibility of the client and us. We charge by the hour to correct the specification and to correct/remove any code already in place that is effected by the specification defect. The implementation of a new requirement added in this way is treated as a change order and the bid and schedule are recast.
The only point here is to get them to understand that the language in the spec is literal and complete. Remember the old adage - Developers feel that anything not explicitly included is excluded; clients feel that anything not explicitly excluded is included.
It is VERY IMPORTANT to realize that the key to using this approach is the communications skills of the developer. It's easy to get this whole thing turned into some sort of a pissing contest in which nobody gets what they want. If the developer is not a skilled, trained, capable communicator (verbally, tonally, via body language, in written words and graphic representation) then it'd hard to do this well.
Very few developers or clients can write a really good Test Plan, but both we and the client want one. If the client doesn't know how to write a plan we're glad to help them do that on a consulting basis, if they don't choose to use our services to help them with the Test Plan then it's their responsibility to get it done well without our help. If they want us to write a Test Plan to their satisfaction that's fine, too, but _they're_ the ones who understand their business, their data and the pathologies that are embedded in both. We can't write a really good Test Plan without that knowledge and we can't bid on what it will take to get it, so it has to be an hourly contract, not part of the orginal bid. Few clients chose to go all the way to a real Test Plan. They find it less expensive to pay to have things fixed as they find them.
Most or our work goes on for years on a single project. (I believe in the old adage that a piece of software isn't really complete until the day it's retired). Our clients keep adding functionality to applications we've done for them, each phase of which is managed as a distinct project with its own specification and test plan. Since we want to keep our clients we also bend the rules on occassion, but not unless everybody understands what's going on and we know what we're going to do to prevent it from happening again.
An ambiguous requirement can lead to serious problems because it doesn't describe what the parties wanted the software to do. An incomplete requirement is more annoying than serious, since it generally means that we forgot to spec something out. The customer must understand that additional work due to an incomplete requirement is no one's "fault" and that the additional functionality will be completed for $x. Ambiguous requirements can be much more messy to resolve. When writing a fixed price contract, clients must understand that requirements must be sufficiently unambiguous that an "impartial third party will be able to divine the intent of the parties". That's why it's really good to publish requirements for comment and sign off at the highest level possible.
A few years back, John Zoltai floated an idea that worked very well for my company. We offered to write the requirements document in a platform independent language. All of that work that was done was billed at the hourly rate. We generated the requirements doc and the logical data model for the client. Once we had a problem definition, which is generally what we did, they client could build the system in any db they wanted to do. The advantage that we had was that if we wanted to do the work, we had the upper hand since we'd just finished weeks/months of understanding the company, the data, and the culture. OTOH, if we thought that the client would be a pain, we could complete the requirements document and still have a successful project. A number of months ago, Mark Yelich and I were discussing V6 and how the new design environment would impact the time required to create a database. Our assumption was that most 4D developers bill on a time and materials basis. Since 4D Insider will allow us to generate structures in seconds, we concluded that developers will have to rethink how to generate revenue. But I digress... 8-)