VFIS Online Training Center website enables Saint Joseph's University and VFIS to provide online distance learning and certification
Northampton, MA - September 25, 2008 - Confluent Forms LLC has developed a new website for Saint Joseph's University, the Early Responders Distance Learning Center, and VFIS to provide an online distance learning platform to the Emergency Service community.
The purpose of the website, the VFIS Online Training Center, is to provide VFIS, the largest provider of insurance, education and consulting services to Emergency Service Organizations, with an online platform that allows them to deliver online training and certification programs to Emergency Service providers such as firemen, policemen, ambulatory providers and other first responders. Under the auspices of Saint Joseph's University and the Early Responders Distance Learning Center (ERDLC) which is hosting the final site, Confluent Forms LLC created a platform that quickly and efficiently delivers these courses, a survey and testing mechanism, and a final certificate of completion.
The site, located at http://vfis.sju.edu, was built using standards compliant XHTML, CSS and AJAX, along with the open source technologies of PHP, MySQL and Apache, along with utilizing Authorize.net's secure payment gateway for e-commerce processing. The site was also built using the proprietary architecture and extensive code libraries of Confluent Forms LLC.
In addition to providing distance learning courses, testing, and certification, the website includes a comprehensive Content Management System (CMS) that enables the website's administrators to manage all aspects of the site.
About Confluent Forms LLC:
Confluent Forms LLC is a boutique branding, graphic design, web design and custom software development firm based in Northampton, MA. Incorporated in January of 2002, Confluent Forms has provided technology consulting, branding, graphic design, web design, PHP and MySQL development, Web 2.0 software development, application development and hosting services to customers from the Fortune 100 to local non-profit organizations, startup businesses and academic institutions.
For More Information:
David Kutcher
President
Confluent Forms LLC
+1-413-303-9612
info@confluentforms.com
http://www.confluentforms.com
How not to destroy a project during the contract phase
Contracts have a funny way of bringing enthusiastic and optimistic partners in a project quickly back to earth and miring them in angry back-and-forth that can soil the project before it even starts.
The following article is based on our experience issuing contracts for Confluent Forms LLC as well as reviewing contracts on behalf of clients when performing technology advising services.
Be equally fair
By default, lawyers will craft a contract that is the most defensive posture for your company. They want you to be on the safe side and in control. The contract is meant to protect you, give you all the rights, and give nothing to the other side. If both sides take this posture you'll end up in a Mexican Standoff with nothing but empty wasteland between you. Every good contract is built on compromise and the desire to see the project succeed. Too much pessimism can be a huge turnoff.
If you make a promise, keep a promise
Salesmen like to be optimistic and promise you the moon, executives want to be realistic and not be held accountable. This behavior often is seen when a sales person promises you the entire project for a specific amount, but then when you read the contract, you see language such as "this is only an estimate and the final project price might vary due to a number of factors". Most customers never notice this line or realize its impact. We have heard of projects in which a price tag of $100,000 was promised, this line was in the contract, and the project ended up costing around $200,000 when all was said and done. Which brings us to our next point...
Definition and Statements of Work
Definition is something often sorely missing from a project. Spending more time defining the project and pricing, and being clear about what the project consists of and how the project will be billed, will save the project from countless misunderstandings, confusion and potential strife. The two sides can be looking at the same one sentence describing a piece of functionality but have widely disparate views on what the description entails. One view could be exceptionally complex and expensive, the other view could be a 30 min endeavor. This can turn into the following exchange:
"Well, the SOW says you're going to implement a 'user profile management' feature to the site, but you've made it so it only captures first name, last name, email address and password. We want it to capture that, their home address, business address, areas of expertise, newsletters they'd like to receive, companies they are affiliated with, etc. etc."
"None of those things are mentioned in the SOW so they aren't going to be implemented in this project... perhaps an add-on phase?"
"What do you mean they aren't in the SOW? It says USER PROFILE MANAGEMENT and those are the pieces of information that are captured in our existing system under the user's profile."
At which point both sides have the option to stand down and accept the other person's point of view or to fight for their opinion of what is stated in the SOW and both yield to negative feelings. The moral of the story? Definition saves projects.
Use project milestones for the payment schedule
We were once involved in a project where the technology firm wanted 40% of a $100,000 project paid upon signing. There was no mention of this huge upfront payment during the project talks, but then upon receiving the contract, there was an invoice for that whopping amount. Needless to say this left a bad taste in the client's mouth and they immediately balked. It is entirely fair to require a percentage upon initiating the project; it is also entirely fair to require a percentage held until the final project is delivered. But rather than having it be 50% upfront and 50% on completion where the client isn't happy at the beginning and the firm isn't happy at the end, we recommend schedules along the lines of 10%, 17.5%, 17.5%, 17.5%, 17.5%, 20%.
Prompt payment and late payment fees
A happy contractor is a contractor that gets paid regularly. An unhappy client is a client that gets billed late fees. Seems simple, right? Contracting firms want to make sure that they get paid for the work they are doing, get paid in a timely manner, and don't get left holding unpaid invoices while the client has the finished product in-hand. At the same time clients rarely like to feel that their work is being held hostage or that they are being threatened into paying by excessive late fees.
Contractors should be entitled to putting a small late fee clause into their contract. They should issue invoices for periodic and smaller amounts so that they can be sure they are being paid regularly and that they aren't left holding too much unpaid work. Clients should be good about paying timely and that timeliness should take the project length into account. If the project is scheduled for 3 months, a 60 day payment period simply can't work. I recommend a 14 day turnaround on all invoices for projects until 4 months, and a 30-day turnaround for projects lasting greater than 4 months. Combined with the milestone payments above, everyone will know when monies are due and at what progress point they are to be paid.
Be clear about ownership of the final product
Technology and ownership can get tricky sometimes, especially when companies try to reuse code and software systems that they've built in the past as a way to build bigger projects quicker and with greater profit margins. In these cases lots of companies like to say that what they've built is a proprietary system and that they are licensing it to the client, which can be fine if the client is given a license to take the complete system and take it elsewhere without selling or distributing it.
But when this isn't fair is when the company puts limitations on the license that it must be hosted on their platform or that the client only owns the data in the system and that the work the client has paid for is only a customization of a proprietary system and not transferable. While firms are entitled to sell ASP-model (Application Service Provider) systems, they should be clear with clients about how this works, the upside as well as the downside.
Be upfront about additional costs to the project
Most clients go into a technology project not knowing much about technology. Many would not know that hosting for a website is something that you need for a website nor how to go about getting "that name thing that I put into the browser". They won't know that the site requires a license for Oracle, or a dedicated server due to technology requirements, or anything like that. Clients need to know about upfront costs before they are sprung with them in the contract or notified about them after the project is completed and they are ready to go live with their site.
Don't hold hostages, define breakaway clauses
The milestones and payment schedules mentioned earlier are good for another thing: breakaway clauses. Nobody wants to have to hold back work from the client until they get paid, and nobody wants to be in a project that is clearly going in the wrong direction. Breakaway clauses and clearly defined milestones allow both sides to amicably walk away from a project at predefined points if it is mutually decided that the project should be put to a stop.
Each contract is different; while the above items won't cover all situations or guarantee that your project goes well, hopefully they'll cause you to take a second look at the contract you are handing to a client or another glance at the contract you are about to sign. And for God's sake, read and re-read that contract, don't skim!
The following article is based on our experience issuing contracts for Confluent Forms LLC as well as reviewing contracts on behalf of clients when performing technology advising services.
Be equally fair
By default, lawyers will craft a contract that is the most defensive posture for your company. They want you to be on the safe side and in control. The contract is meant to protect you, give you all the rights, and give nothing to the other side. If both sides take this posture you'll end up in a Mexican Standoff with nothing but empty wasteland between you. Every good contract is built on compromise and the desire to see the project succeed. Too much pessimism can be a huge turnoff.
If you make a promise, keep a promise
Salesmen like to be optimistic and promise you the moon, executives want to be realistic and not be held accountable. This behavior often is seen when a sales person promises you the entire project for a specific amount, but then when you read the contract, you see language such as "this is only an estimate and the final project price might vary due to a number of factors". Most customers never notice this line or realize its impact. We have heard of projects in which a price tag of $100,000 was promised, this line was in the contract, and the project ended up costing around $200,000 when all was said and done. Which brings us to our next point...
Definition and Statements of Work
Definition is something often sorely missing from a project. Spending more time defining the project and pricing, and being clear about what the project consists of and how the project will be billed, will save the project from countless misunderstandings, confusion and potential strife. The two sides can be looking at the same one sentence describing a piece of functionality but have widely disparate views on what the description entails. One view could be exceptionally complex and expensive, the other view could be a 30 min endeavor. This can turn into the following exchange:
"Well, the SOW says you're going to implement a 'user profile management' feature to the site, but you've made it so it only captures first name, last name, email address and password. We want it to capture that, their home address, business address, areas of expertise, newsletters they'd like to receive, companies they are affiliated with, etc. etc."
"None of those things are mentioned in the SOW so they aren't going to be implemented in this project... perhaps an add-on phase?"
"What do you mean they aren't in the SOW? It says USER PROFILE MANAGEMENT and those are the pieces of information that are captured in our existing system under the user's profile."
At which point both sides have the option to stand down and accept the other person's point of view or to fight for their opinion of what is stated in the SOW and both yield to negative feelings. The moral of the story? Definition saves projects.
Use project milestones for the payment schedule
We were once involved in a project where the technology firm wanted 40% of a $100,000 project paid upon signing. There was no mention of this huge upfront payment during the project talks, but then upon receiving the contract, there was an invoice for that whopping amount. Needless to say this left a bad taste in the client's mouth and they immediately balked. It is entirely fair to require a percentage upon initiating the project; it is also entirely fair to require a percentage held until the final project is delivered. But rather than having it be 50% upfront and 50% on completion where the client isn't happy at the beginning and the firm isn't happy at the end, we recommend schedules along the lines of 10%, 17.5%, 17.5%, 17.5%, 17.5%, 20%.
Prompt payment and late payment fees
A happy contractor is a contractor that gets paid regularly. An unhappy client is a client that gets billed late fees. Seems simple, right? Contracting firms want to make sure that they get paid for the work they are doing, get paid in a timely manner, and don't get left holding unpaid invoices while the client has the finished product in-hand. At the same time clients rarely like to feel that their work is being held hostage or that they are being threatened into paying by excessive late fees.
Contractors should be entitled to putting a small late fee clause into their contract. They should issue invoices for periodic and smaller amounts so that they can be sure they are being paid regularly and that they aren't left holding too much unpaid work. Clients should be good about paying timely and that timeliness should take the project length into account. If the project is scheduled for 3 months, a 60 day payment period simply can't work. I recommend a 14 day turnaround on all invoices for projects until 4 months, and a 30-day turnaround for projects lasting greater than 4 months. Combined with the milestone payments above, everyone will know when monies are due and at what progress point they are to be paid.
Be clear about ownership of the final product
Technology and ownership can get tricky sometimes, especially when companies try to reuse code and software systems that they've built in the past as a way to build bigger projects quicker and with greater profit margins. In these cases lots of companies like to say that what they've built is a proprietary system and that they are licensing it to the client, which can be fine if the client is given a license to take the complete system and take it elsewhere without selling or distributing it.
But when this isn't fair is when the company puts limitations on the license that it must be hosted on their platform or that the client only owns the data in the system and that the work the client has paid for is only a customization of a proprietary system and not transferable. While firms are entitled to sell ASP-model (Application Service Provider) systems, they should be clear with clients about how this works, the upside as well as the downside.
Be upfront about additional costs to the project
Most clients go into a technology project not knowing much about technology. Many would not know that hosting for a website is something that you need for a website nor how to go about getting "that name thing that I put into the browser". They won't know that the site requires a license for Oracle, or a dedicated server due to technology requirements, or anything like that. Clients need to know about upfront costs before they are sprung with them in the contract or notified about them after the project is completed and they are ready to go live with their site.
Don't hold hostages, define breakaway clauses
The milestones and payment schedules mentioned earlier are good for another thing: breakaway clauses. Nobody wants to have to hold back work from the client until they get paid, and nobody wants to be in a project that is clearly going in the wrong direction. Breakaway clauses and clearly defined milestones allow both sides to amicably walk away from a project at predefined points if it is mutually decided that the project should be put to a stop.
Each contract is different; while the above items won't cover all situations or guarantee that your project goes well, hopefully they'll cause you to take a second look at the contract you are handing to a client or another glance at the contract you are about to sign. And for God's sake, read and re-read that contract, don't skim!
How to select the right web design and web development firm
As a web design and web development firm, Confluent Forms LLC has responded to quite a few Requests for Proposals (RFP), seen hundreds as they've passed through the RFP Database, helped organizations such as the American Society of Colon and Rectal Surgeons and Social Jane through their RFP process in selecting a web development firm and technology decisions, and thrown out more RFPs than we can count. Having been on all sides of the process we'd like to pass along a bit of the knowledge we've gained in how you should select your web design and web development partner.
Things to keep in mind about your project...
1) Depending on the size and scope of your project there is a strong likelihood that you will need the product developed for you to last a few years (average software or website is 3 to 5 years).
2) If the site is complex, generally speaking, other companies detest supporting someone else's work, so you might have trouble finding support if you part ways with your initial developer.
3) Most web projects aren't one-time endeavors, but are continually updated, upgraded, overhauled, etc. to meet your organization's changing needs.
4) Know your own project! Before you even begin to engage others, especially those that you'll be paying money to, define your project to the best of your ability. Try to figure out what you need and what you don't need, how much you can afford to spend, what your timeline is, etc.
Evaluate their portfolio...
It's easy to get overwhelmed when looking at the portfolios of web design and web development companies. Each company will have a wide range of projects and clients that it is easy to get confused. Name-dropping and splashy work can sometimes distract you from pure objectivity.
1) Look for projects similar to your own project. If you are looking for custom software, evaluating logo designs doesn't make much sense, nor does looking at complex software applications if you are looking for Flash animations. If you're looking for design work, look for work that is similar to the look that you'd like for your own project. Evaluate apples to apples.
2) Go beyond the names. Find out exactly what the company did for each specific client project. They might list an impressive client, but upon asking, you might learn that they worked for that client under a previous employer or that the work they did for that client was miniscule.
3) Look for repeat clients. Nothing speaks louder towards a client's satisfaction with a company than the re-hiring of the company for multiple projects.
Think of them as your newest business partner...
If you were going to bring in a new part-owner of your business, you'd evaluate that business partner on in a number of different ways. The same applies for your web site or web-based software since, as mentioned before, you'll probably need it to be supported for 3 to 5 years.
1) Establish a rapport. You're going to be working with them pretty closely for the next few months and years so it's important that you establish a good rapport with them and keep it positive. This is especially important as having a good working relationship with your development team will lead to your requests being handled promptly and efficiently.
2) Evaluate their team. It's an open secret that firms often have an A-team and a B-team, senior and experienced people and newbies. You should know the players within the company that you're working with and insist/require that they are assigned to you as your permanent team.
3) Check on their stability. People tend to put a greater focus on the initial project while completely forgetting about the long period after the project launches that you need to use and maintain it. Since projects are often multi-year commitments, you need to make sure that the firm you are partnering with will be there for you through the years. Have they been in business for a number of years, have there been any recent changes to their staffing, etc.
4) Identify who speaks for the company. Salesmen are good at doing what they were hired to do (make sales), but they often disappear once the project starts. For a successful project the person who committed the project should be an active participant from start to finish.
And finally... the 'ities, in no particular order
1) Proximity. Comfort level is huge when it comes to web design and web development. Will you be able to communicate your needs effectively if the team you're working with isn't in the same neighborhood, city, state, or even country? Whatever the distance, the team needs to make you feel comfortable with their distance from you and communication channels.
2) Availability. If you're doing high-volume e-commerce through your website and it's down for an unknown reason, you will most likely want to reach someone. Will there be someone answering the phones? Will they be able to quickly get to work on your site's problem? And how responsive will they be with your initial project or will it be one person working on it part-time?
3) Understandability. Tech-speak can be hard enough to understand to the uninitiated. Accents, fast talkers, buzzword-speakers and poor telephone connections can make it even harder. Getting back to comfort level, you need to feel 100% comfortable that you and the team you hire are crystal clear in understanding each other.
4) Ability. Make sure they can do the job that you're hiring them to do. You don't want your project to be their learning project, their first time, or their way of training interns. It's your time, your money and your project.
5) Affordability. Be realistic and expect them to be realistic. A trick that some less-than-reputable firms like to take is to give you a fixed price but then have a caveat in the contract that says all pricing is hourly and any firm numbers are merely estimates. You want firms to commit to specific pricing, keep you appraised of pricing changes, and be clear about how much aspects cost.
Things to keep in mind about your project...
1) Depending on the size and scope of your project there is a strong likelihood that you will need the product developed for you to last a few years (average software or website is 3 to 5 years).
2) If the site is complex, generally speaking, other companies detest supporting someone else's work, so you might have trouble finding support if you part ways with your initial developer.
3) Most web projects aren't one-time endeavors, but are continually updated, upgraded, overhauled, etc. to meet your organization's changing needs.
4) Know your own project! Before you even begin to engage others, especially those that you'll be paying money to, define your project to the best of your ability. Try to figure out what you need and what you don't need, how much you can afford to spend, what your timeline is, etc.
Evaluate their portfolio...
It's easy to get overwhelmed when looking at the portfolios of web design and web development companies. Each company will have a wide range of projects and clients that it is easy to get confused. Name-dropping and splashy work can sometimes distract you from pure objectivity.
1) Look for projects similar to your own project. If you are looking for custom software, evaluating logo designs doesn't make much sense, nor does looking at complex software applications if you are looking for Flash animations. If you're looking for design work, look for work that is similar to the look that you'd like for your own project. Evaluate apples to apples.
2) Go beyond the names. Find out exactly what the company did for each specific client project. They might list an impressive client, but upon asking, you might learn that they worked for that client under a previous employer or that the work they did for that client was miniscule.
3) Look for repeat clients. Nothing speaks louder towards a client's satisfaction with a company than the re-hiring of the company for multiple projects.
Think of them as your newest business partner...
If you were going to bring in a new part-owner of your business, you'd evaluate that business partner on in a number of different ways. The same applies for your web site or web-based software since, as mentioned before, you'll probably need it to be supported for 3 to 5 years.
1) Establish a rapport. You're going to be working with them pretty closely for the next few months and years so it's important that you establish a good rapport with them and keep it positive. This is especially important as having a good working relationship with your development team will lead to your requests being handled promptly and efficiently.
2) Evaluate their team. It's an open secret that firms often have an A-team and a B-team, senior and experienced people and newbies. You should know the players within the company that you're working with and insist/require that they are assigned to you as your permanent team.
3) Check on their stability. People tend to put a greater focus on the initial project while completely forgetting about the long period after the project launches that you need to use and maintain it. Since projects are often multi-year commitments, you need to make sure that the firm you are partnering with will be there for you through the years. Have they been in business for a number of years, have there been any recent changes to their staffing, etc.
4) Identify who speaks for the company. Salesmen are good at doing what they were hired to do (make sales), but they often disappear once the project starts. For a successful project the person who committed the project should be an active participant from start to finish.
And finally... the 'ities, in no particular order
1) Proximity. Comfort level is huge when it comes to web design and web development. Will you be able to communicate your needs effectively if the team you're working with isn't in the same neighborhood, city, state, or even country? Whatever the distance, the team needs to make you feel comfortable with their distance from you and communication channels.
2) Availability. If you're doing high-volume e-commerce through your website and it's down for an unknown reason, you will most likely want to reach someone. Will there be someone answering the phones? Will they be able to quickly get to work on your site's problem? And how responsive will they be with your initial project or will it be one person working on it part-time?
3) Understandability. Tech-speak can be hard enough to understand to the uninitiated. Accents, fast talkers, buzzword-speakers and poor telephone connections can make it even harder. Getting back to comfort level, you need to feel 100% comfortable that you and the team you hire are crystal clear in understanding each other.
4) Ability. Make sure they can do the job that you're hiring them to do. You don't want your project to be their learning project, their first time, or their way of training interns. It's your time, your money and your project.
5) Affordability. Be realistic and expect them to be realistic. A trick that some less-than-reputable firms like to take is to give you a fixed price but then have a caveat in the contract that says all pricing is hourly and any firm numbers are merely estimates. You want firms to commit to specific pricing, keep you appraised of pricing changes, and be clear about how much aspects cost.
Our website is only one page
Responses to our website have ranged from "could you not afford more than 1 page?" to "it's so cool you just put one page up there, I wish my web-dev firm would do that."
So what does it all mean?
I respect simplicity. In my high school art class I had a teacher that over and over would drill into our heads "less is more", which when applied to art and design is definitely a good thing to remember. Somehow that got lost on me for a long time as I felt that I needed to convey everything possible when creating our company's primary mode of communication to potential clients. I felt we needed to have content, and words, and buzzwords, and thought-provoking commentary that showcased how right we were for the job, any job, and how we understood their potentially unique situation. We wanted to show that we were just as qualified for a project as the Razorfish/Agency.com/Organic/Sapient/Scient's of the world. We were brainstorming on the content for about a year, creating the information architecture, writing the content, editing the content, re-editing the content, etc.
We started working on the design of the site and our designer created a great homepage. We loved the homepage. The only problem was it didn't really carry though to an interior page. We were getting lost in our own content.
We put the project on the back burner, yet again, and thought about it for a month or so. After a bit it hit us: we didn't need to mince words and sugarcoat it all. We have successful projects that we can show that speak volumes towards the work we do. We have work ranging from Pfizer Pharmaceuticals to Amherst College to Focus Talent & Promotions. We have worked with Fortune 100s, non-profits, universities, startups... projects of all shapes and sizes that illustrated our delivery of quality work.
So why drown that message in pages and pages of content?
We took the most important parts of the content we had written consisting of a short blurb about us, a listing of the services we offer, our contact information, and a listing of our favorite client projects, and said "It Is Done".
Our new website has sparked discussion, been favorably reviewed, and been promoted, all of which translates into added publicity and greater name recognition.
Communicating your mission, services, expertise and experience is the primary purpose of a service company's website. As the web has evolved, saavy web visitors' attention spans have shrunk considerably. Bounce rates of 50% are a symptom of this; the challenge is how to grab their attention before they've already left. In 2000 you might have had 30 to 60 seconds, now you're lucky if you get 5 to 10 seconds.
If you need them to click into your site there had better be a compelling pitch to get that click otherwise they'll have left at your splash page.
So what does it all mean?
I respect simplicity. In my high school art class I had a teacher that over and over would drill into our heads "less is more", which when applied to art and design is definitely a good thing to remember. Somehow that got lost on me for a long time as I felt that I needed to convey everything possible when creating our company's primary mode of communication to potential clients. I felt we needed to have content, and words, and buzzwords, and thought-provoking commentary that showcased how right we were for the job, any job, and how we understood their potentially unique situation. We wanted to show that we were just as qualified for a project as the Razorfish/Agency.com/Organic/Sapient/Scient's of the world. We were brainstorming on the content for about a year, creating the information architecture, writing the content, editing the content, re-editing the content, etc.
We started working on the design of the site and our designer created a great homepage. We loved the homepage. The only problem was it didn't really carry though to an interior page. We were getting lost in our own content.
We put the project on the back burner, yet again, and thought about it for a month or so. After a bit it hit us: we didn't need to mince words and sugarcoat it all. We have successful projects that we can show that speak volumes towards the work we do. We have work ranging from Pfizer Pharmaceuticals to Amherst College to Focus Talent & Promotions. We have worked with Fortune 100s, non-profits, universities, startups... projects of all shapes and sizes that illustrated our delivery of quality work.
So why drown that message in pages and pages of content?
We took the most important parts of the content we had written consisting of a short blurb about us, a listing of the services we offer, our contact information, and a listing of our favorite client projects, and said "It Is Done".
Our new website has sparked discussion, been favorably reviewed, and been promoted, all of which translates into added publicity and greater name recognition.
Communicating your mission, services, expertise and experience is the primary purpose of a service company's website. As the web has evolved, saavy web visitors' attention spans have shrunk considerably. Bounce rates of 50% are a symptom of this; the challenge is how to grab their attention before they've already left. In 2000 you might have had 30 to 60 seconds, now you're lucky if you get 5 to 10 seconds.
If you need them to click into your site there had better be a compelling pitch to get that click otherwise they'll have left at your splash page.
Subscribe to:
Posts (Atom)



