1. Not Understanding Client Needs

a. You have listened, but have you heard?
b. Have you asked the right questions?
c. Are you merely doing what the client asks, or are you truly addressing their needs?

2. Over Promising

a. Are the client’s requests reasonable?
b. Does your new business guy know your capabilities?
c. Is it worth it?

3. Bad Process

a. Poor planning
b. Poor project management
c. Wrong priorities
d. Poorly defined roles and responsibilities

4. Poor Execution

a. Poor talent
b. Bad direction
c. Insufficient quality control
d. Inexperience

5. Under Pricing

a. Ignorance
b. Competition
c. Fear

6. Not Controlling Change (Scope Creep)

a. Who says yes (no)?
b. What were the client’s expectations
c. Implications of saying yes
d. What is your protocol for a change or additional work order?

7. No Contingencies

a. What ifs
b. Unknowns
c. Good, better, best
d. Wiggle room
e. Plan B

8. Poor Communication

a. Paper, e-mail or phone call?
b. Does the right person know
c. Timing
d. Beg for forgiveness or ask for permission?
e. Not enough information given

9. Not Getting Approvals at Key Milestones

a. Defining key milestone
b. Someone has to sign off
c. Ramifications

10. Bad Client Relationship

a. Lack of trust
b. Dictator syndrome

Almost every client I talk to wants the ability to make edits to their site without having to pay a developer. This sounds great and with all the content management products, blog software, portal frameworks advertised the technology is cheaper, more available and simpler to use than ever before.

Just like building a house, creating a web site takes craft. It takes more than tools. There are a lot of lay people that have tools, but can’t build a house and there are a lot of companies with content management systems (CMS) that can’t manage a web site.

Too many times I have seen a group of talented folks build a beautiful site and within a year it is an embarrassment because of CMS abuse. Wacky type, garish colors, poor formatting destroy the integrity of the design. This is a loose-loose situation: the client looses the value of good information architecture and design for which they paid, the visitor doesn’t get the experience they deserve and the shop that put their soul into the site doesn’t get to see the benefits of their hard work realized.

Many shops use the manta “Just give the client what they want.” Those shops are only in it for money and have the wrong approach. It is our job as web professionals to guide and educate clients through the process of planning and developing a web site. By conducting diligent analysis of business needs, stakeholders, and resources the best solution is revealed. Sometimes it involves a CMS and sometimes not.

When deciding on a CMS, here are some important considerations:

• How often will the content actually be updated? And will the cost of the CMS outweigh the cost of hiring a developer to make updates.
  
• What future considerations are there for site additions and how can the CMS be modified to include new content and new functionality?
  
• Does the client need to change the navigation structure of the site or just edit specific sections?
  
• Who will be managing the site and what is their time constraints, and skill level in copywriting, and graphic design. Yes, graphic design is not only graphics; it is text formatting and typography.
  
• What is the client’s workflow regarding publishing content? Is there proofing? Is there an approval process? How is this communicated?
  
• What types of content will need to need to be managed: news releases, images, charts, downloadable documents and user permissions?
  
• What format is the above material in before it gets published to the web? How does the conversion to web ready files, data or info handled?
  
• Are there any other technologies or systems which the CMS must interact?

Obviously, these are just a few concerns, but the idea is - get the big picture. Having control is appealing, but can the client handle it? Help them realize the work and effort involved. They will be happier in the long run and you will be too.

The concept of Barely Sufficient in web development and project management was first introduced to me as part of Agile methodologies. When learning about Agile, a practitioner of waterfall methodologies, like myself, often thinks Agile means reckless development without planning and documentation – do,do,do; redo; then do some more. But the real message Agile preaches is not to do too much planning or documenting because things change rapidly during the lifecycle of a project. Only do what is Barely Sufficient regarding planning and documenting and the real progress is made by actually writing code.

Time spent on documentation is essential regardless of the methodology. It requires careful thought to write something that others will read and use as information for development. This exercise exposes gaps in requirements and can help uncover problems ahead. It is also used to communicate to stakeholders their needs will be addressed. The amount of time spent on documentation is directly proportional to the type of audience for which it is intended and the size of the project. Technical folks probably require more details than management. Marketing folks are probably more interested in content and design than the technical under-workings of a site. Write only what is needed to move the project to the next step. Then at a later time add more as needed. It will probably be more accurate than if it was written when less was known.

Barely sufficient can also be applied to how much programming is required. It is wise to write only enough code to meet the requirements. Then, if there are changes, less rework is needed. The trick is knowing the exact requirements and goals, making sure they’re correct by effectively communicating with the stakeholders and communicating them properly to the team for execution - easier said than done.

The bottom line: efficiency is time and money. Barely Sufficient goes a long way in keeping unnecessary work out of the project saving resources for things that matter.

I've been reviewing project mangement software to use in our business. The robust Microsoft Project was the first to be crossed off the list. It certainly would do the job, but the server version is too expensive and we need to share information.

The ubiquitous Outlook/Exchange was then considered. It has tasks, a calendar, public folders, contacts and now SharePoint. All useful, but it is not really suited for our needs.

A portal approach using DotNetNuke could work. The price is right, but I couldn't find any modules that provide task distribution and deadline notification, important features.

37 Signal's baby, Basecamp, is a contender. It is easy to use, web based and has plenty of features, but it's a bit pricey for us.

JotSpot Wiki is a nice site with a bunch of apps from which to choose. Collectively they can be used to manage a project, but they are not related making it difficult for team members to easily find information. 

So far, I like The Copper Project the best. It comes in two versions: standard and corporate. Of course the corporate version has all the features we need, but it is more expensive. However, it's cheaper than Basecamp.

The jury is still out and hopefully we'll find some young energetic entrepenuers out there with a good product that isn't too pricey and works well. The search continues...

Matt Linderman at 37 Signals wrote a post on their blog singing the praises of their "simpler is better", iterative methodology by remarking how confidence plays an important role in development practices.

I commented with a more corporate viewpoint and several others have elaborated on the realities of working for clients.

Methodology and practice is a topic on a lot of project manager's minds and it seems I am not alone in my uncertainty. I try to look at each project and team. Then see what will work for that situation. At least I'm exploring and not stuck with the same 'ol, same 'ol, but I can say it is rare the any project gets done without a fair amount of planning and paper work.

An often underestimated part of creating a web site is content development. The creative direction is given attention and technical aspects also are in the forefront, but content is often not addressed early in the lifecycle as it should be.

Content should be the first concern after planning has been completed. Designers can more easily visualize how to present the content if it exists than not. They can plan their layouts to accommodate the different formats of text and graphical information and eliminate the changes that always come with receiving content late in the design process.

When gathering and organizing content, the structure of the site also takes shape; the number of sections, subsections and pages often change from the proposed site map during this process. Content gets added, combined, edited and removed as it goes through the revision and approval process. It’s also far easier to revise and proof content in a text document than in web pages.

Beginning with database design, it’s also important to have content ready during development. The developer can tell what the data types, text character lengths, hierarchies and relationships are which is important to creating an optimized data structure. Programmers can use it as real, test data ensuring their code is sufficiently crafted to perform business logic and display the interface properly.

At crunch time, the end of the project, it’s far better to have content finished early, or as least in a “final” state, than to have to incorporate makeshift text and graphics into the site when functional testing, or when everyone is seeing the site for the first time. Poor copy distracts from the review process. There are so many other pressing issues at this time and having to create content late often causes the project miss deadlines, when it could have been avoided.

A particular situation where careful attention to developing content is crucial, is with small companies, or companies that are new to the web. Often they think they have enough information to make a good site, but when it is placed in the site the content is weak, incomplete, or does not fit well into how the site had been planned. Then what do you do? Change the site, or change the content? There’s a costly miss-match.

If search engine optimization and search engine marketing are important, content has to be created early in order for it to be optimized properly and the site built correctly. Although copy should be written so it reads well to the audience, keywords and search phrases should be incorporated. Any information hidden to search bots in graphics should be exposed by using the correct HTML attributes, or appropriate captions. Having both company specific information and general industry information helps round out content aiding in search rankings.

Source material for content can come from several areas:

Client – Have them gather information and past documentation.

Industry – Industry web sites and publications often have information that can be easily modified.

Competitors – Read the client’s competitor’s sites and collateral material. See how they are presenting their message.

Suppliers – If your client is a manufacturer or distributor, their suppliers and manufacturers have catalogs and sell sheets loaded with useful information.

Customers – Customers can provide a different perspective and may have unexpected information especially if looking for applications and uses of products.

Just as design and development specialists are required to make a good site, copyrighters are also important. Visitors spend more time reading than anything else so the copy must be well written to communicate effectively and project the proper image.

Do yourself a favor on your next web project. Concentrate on content. Afterall, it’s why you’re building a site in the first place, and the site will be better for it.

An all too common practice in corporate America is decision by committee. Countless meetings are held each week where people stare at each other across conference room tables and decide not to decide – productivity at it finest. This tradition is especially painful when applied to creative decision making. Advertising, marketing, branding and even web design is incredibly complex and subjective.

Because of the variety of skills and knowledge of its members, the committee is viewed by management as an entity with built in checks and balances thus lessening the risk of a bad decision. This is a fallacy; plenty of bad decisions come from committees. The possibility of a good design getting approved by a committee is slim. The result is what the committee considers safe, and safe is usually not good. With creativity, without risk there’s little reward.

In order to communicate visually, like with graphic design, a certain amount of responsibility is placed on the viewer. When viewers have different backgrounds, educations and experiences their level of understanding varies greatly. Even after several hours of explanation and justification by the creator, the decision makers often don’t comprehend and perceive what they’re seeing similarly.

Ever experience a group of people in a committee deciding what to order for lunch? Pizza seems to be popular, but if you followed each person to lunch individually, I bet none eat pizza. Why do people choose something as a group they would not choose themselves? Some people think “what would they think rather than what do I think.” People that may not be qualified to make a sound decision as individuals are able to influence others in a committee. People that avoid conflict go with the flow increasing the majority. These phenomena are termed ‘group think’ and lead to bad results in committees.

How can this unfortunate situation be avoided? As creators and experts, it’s our job to persuade our clients against this creative decision making approach. Ask your client to choose a qualified stakeholder with the knowledge, experience and ability to make the definitive decision. He/she may choose, or be required to get input from others, and should do so, but the dynamics here are different than with a committee. If they are unwilling to do so because they do not have the right person, their trust must be gained to allow you, as the expert, to make the decision for them. If they won’t do that because it’s not how they do things, be prepared to deal with the tedious task of getting buy in from the majority.

When going into a project ask how decisions are going to be made and if it’s by committee make sure you account for the extra effort required to communicate the design concept and gain sufficient understanding from the group for approval. Carefully planned presentations and one-on-one explanations will be needed. These can quickly consume a lot of unexpected hours from the budget. Also in the proposal detail how you plan to communicate with the group, the revision/approval process, what is in scope and what happens when the process gets excessive.

I’m always looking for simple and cheap ways to help manage projects. Whether they’re spreadsheets, Post-it Notes or MS Outlook, tools make a difference.

Three core functions of managing web projects are task distribution and notification, tracking the amount of work performed and reporting progress or status. Ideal project management applications do all that and more, but they can be complicated and expensive. Blogs are simple, free and suitable for at least two of the three functions mentioned above.

By setting up categories useful to your situation, blogs can work very well to help manage tasks and issues and log project activity. They can also be a central repository for project information and related documentation. Here’s an example of possible category structure:

Project A
- Active Tasks
- Completed Tasks
- Active Issues
- Solved Issues
- Red Flag
- Status Reports
- Files

The Project Manager creates posts and team members use comments to communicate. Everything is ordered by date. When a post’s status changes, the PM simply edits it and moves it to another category. If your blog has RSS feeds they can be used for notification as tasks, issues and comments get posted. Some blog software products allow for membership so categories and posts can be hidden to certain users. Clients can even be folded into the mix.

When working with vendors there’s always the risk they will jeopardize the outcome of a project, hurt your relationship with the client and cost you a lot of money. It’s best to try to minimize this risk and the best way is with a service level agreement. This contract should require a signature, be a binding, legal document and contain clauses that specifically address potential problems.

Some general recommendations:

• Clearly state your expectations on quality.
• Establish the fact you are their client and they work for you, not your client.
• Define communication channels and the proper protocol. This is essential in maintaining control.
• If possible, keep ownership of all deliverables.
• Outline responsibilities for all phases of the project.
• Require they follow best practices and deliver good work. Have a clause that states you can audit their work at defined intervals, or when the project is suspected to be affected.
• State any loss due to missed deadlines or unacceptable deliverables is their liability.
• Require detailed plans and necessary documentation demonstrating they know what they are doing.
• Determine lead and tag times, turn around times and expected response times.
• Have a change control process that details how changes are approved and incorporated into the project’s scope.
• List the consequences for failure to meet requirements and the escalation/arbitration process.

These are just some basics requirements any good service level agreement should have. Remember this is an agreement so it is important to review this with your vendor, discuss each requirement and customize it so both parties can really agree to follow it.

The two most common ways to price interactive work are Fixed Price and Time & Materials. Each method has its pros and cons that greatly affect the buyer and seller of the services.

Fixed Price

Fixed Price is popular with ad agencies and communications firms doing interactive work. It’s how they have traditionally priced their services and is client friendly, because with Fixed Price the risk to produce the job, at the quoted price, lies with the seller. When pricing a project this way it is imperative that the project’s requirements are determined and the scope is tightly controlled. Any complications, rework, or excessive man-hours because of underestimating required time, unseen issues, or inexperience are the cost of the seller. The only time the price is usually renegotiated is when the requirements change, or the buyer requests a change of scope.

When calculating a Fixed Price estimate is it important to figure in contingencies for the unknowns and potential problems, in addition to a profit margin. Counting just man-hours usually means an unprofitable situation. There are several ways to include these cushions: applying a multiplier, padding hours, and adding a risk contingency cost based on project requirements are a few.

Time & Materials

Because of the difficulty of gathering requirements and establishing a detailed project scope, Time & Materials is how most IT companies price their services. This method puts the risk on the buyer to get the project completed within their budget and can be unfavorable in competitive environments, or unacceptable in RFPs. An estimate with a price range is usually proffered with the proposal/contract. Initial estimates can range in excess of +/- 25%. Most buyers like the price to be accurately estimated, but this arrangement is more flexible than Fixed Price. Additional estimates are often given as requirements become available, or as work is completed. Any changes are simply billed when they are incurred.

Do not mix the two methods. Real problems arise when a solid price is quoted in a proposal/contract that has been calculated using Time & Materials formulas. Even if you plan to bill using Time & Material costs, it rarely adds up and the initial price quote is all the buyer cares about.

Each method is effective when used appropriately. Rather than always pricing work the same way, let the market and project dictate which method is best.

I understand you’d like to make some changes to the design of your web site. It's certainly your prerogative to do so, but please allow me to provide some rationale and justification for the design and recommend the best way to make changes.

While planning the design, specific requirements were determined that dictated several aspects of the design: style, structure, features, and ease of maintenance to name a few. During the creative process these requirements were integrated into the design along with current designs trends, compatibility with existing collateral, and coexistence with the company logo. The designer and creative team also infused their vision and expert judgement into the design and the results are the culmination of several iterations of this process.

Once completed, a design has balance between individual elements and overall integrity. Any changes to these elements should be done to maintain this balance and integrity. The best way this is achieved is by using, through repetition and variation, the graphical lexicon already available from the design: colors, type choices, textures, lines, shapes and effects. Introduction of any new elements into this lexicon can easily upset the balance and weaken the integrity of the design.

You like the design, or at least you say you do. We like the design. It represents your company well in the market place. It stands up against current trends and styles and it meets the requirements. Before changing anything, we ask to go through the same process as initially done, letting those you trusted to create the site workout a solution that addresses the need for a change. Don’t just go with someone’s suggestions even though they may seem valid at first and the person is respected. Before making changes, the benefits of the changes should be fully considered and weighed against the potential impact and resulting expense.

For the past year I have witnessed, an unfortunate saga: a web project led by a marketing firm that partnered with an IT vendor gone bad. The marketing firm has some web experience, but not substantial enough to produce the site alone. An IT “partner” was needed for technical resources and experience in the client’s business sector.

Here’s a list of events and circumstances that have transpired with this relationship:

• Partner could not satisfy interface design requirements. The marketing firm ended up doing a lot of extra work not budgeted
• The first demo of the beta site was not ready and had a lot of bugs. The presentation had to be conducted carefully skipping the functionality that did not perform correctly
• During periodic reviews, revisions were not implemented correctly, or in a timely manner, creating more unbudgeted work for the marketing firm
• Requirements continued to be unmet creating a great deal of frustration and doubts of the project’s success. The “partner” even refused to comply with contractual requirements for no legitimate reason
• Subsequent site demos were done with mixed and often embarrassing results
• After site launch, errors were occurring, excuses, assumptions and accusations abound
• Now the focus has turned to contractual obligations and possible litigation

It’s a shame there are unprofessional companies like the vendor in this story. This company lied, cut corners, had no respect for their client, or the project and obviously bit off more than they could chew.

All these issues are a Quality Control (QC) problem. A good QC plan could have brought attention to the trouble early and early usually means with less costs, or consequences.

A good QC plan:

• Is part of the contract or separate service agreement
• Details the QC process
• Lists requirements, tolerances, expectations, practices
• Assigns roles and responsibilities
• Has a schedule for periodic, performance reviews (with short intervals)
• Explains the consequences for failing to meet requirements

Marketing firms, agencies and other communication firms involved in web development often do not have the resources for this responsibility. A solution would be to hire a consultant to handle quality control. He/She would audit the vendor and assure compliance to contractual requirements and make sure best practices are adhered to during development. The money spent on this consultant would have minimized the extra burden on the marketing firm’s resources. If this person had the right skill set, he/she could also have assisted in development at times where the vendor faulted, keeping the quality of the project intact.

Don’t put your company in this situation. Plan for how Quality Control will be addressed and how these risks will be mitigated. You’ll sleep better for it.

Establishing a schedule during planning and getting agreement from all parties is an important part of any project. Once the schedule is accepted, maintaining it during production goes a long way to prevent issues that can jeopardize a project’s success.

Momentum
A great deal of effort is consumed during the start-up of any activity. Having stops and starts in production is costly and can ruin a budget very quickly. When a project is moving along smoothly and work is getting completed, effort is directed to the resources doing the work while administration is minimal.

Continuity
Continuity is an essential part of any creative process. Once a designer, or programmer is in their “zone” they are very productive and the quality of work is at its peak. After a long break, it may be impossible for a designer to get back into the same mind-set to finish their work as intended. Technical people also loose their perspective and have to spend time and effort to pick up where they left off.

Risk
The longer a project takes to complete the higher the probability of failure. This risk is often overlooked, especially by the client, since it’s the supplier’s responsibility to complete the project successfully. Business needs, creative direction, financials, technology, and resources change over time. The project may be affected by any of these changes and require a change in scope.

Cash Flow
Delays affect cash flow in several ways. Billing may be delayed if it’s contingent on milestones, or deliverables and expenses my be higher because of availability, or market rates. Available funding may no longer be available.

Take Precautions

Although work stoppages may not be preventable, there are some ways to plan and create incentives to keep a project on schedule, or minimize the impact they have:

• Have clauses in your contract that address how delays will be handled.

• Do not have your billing contingent on deliverables or milestones. Get paid on schedule even though work may be stopped.

• Only guarantee rates and/or expenses for a specific time period.

• Designate desirable stopping points at milestones so productive stretches in the schedule won’t be interrupted unnecessarily.

• Check resource availability for worst case scenarios, have back-ups and include this extra expense in the project cost.

• Don’t begin work until the schedule is agreed upon.

• Work in short cycles that naturally create stopping points.

It’s very difficult to estimate time to complete work even for experienced people. As a project manager, I often have to rely on developers and designers to provide estimates on how long it will take them to complete their assigned tasks. I am surprised at the inaccuracy of the results, but have found some commonalities.

People usually underestimate time required to complete work, and not just by a little, often as much as 50%. After some discussion with team members, it became apparent that unless people had a previous example on which to base their estimating, they had difficulty imagining how the new work will happen. People generally just run through the core activity and estimate how long it should take, not would take.

Rework is also not considered. Sometimes it is because they assume it will make them look bad when they have to justify their estimate if they have included rework. Other times it is because they think they won’t make mistakes this time. Having an inaccurate estimate is far worse than doing something twice. Nothing is accomplished in a straight line.

Start-up time and close time are also not included. Discussing issues, looking for resources, reading documentation, configuring software, installing updates, obtaining permissions, refreshing one’s memory and getting “in the zone” are all part of the task at hand and must be included.

One technique I use that has been very successful is to estimate how long it will take to do the core task with no rework, then double it.

Another situation that adds complexity to estimating time is when the person who will actually end up doing the work is not the one estimating the time to do it. Even two people with comparable skill sets may take quite a different amount of time to complete the same work. Some people are more detailed and double-check everything; some are more organized and have less start-up time, while others are just faster. If the lowest common denominator is used there is risk of the estimate being excessive. How does one find the average or better yet a weighted average? I’ve used:

Weighted Average = (longest time estimate * .75) * 2

I like to err on the high side.

A project I’m working on now requires an accurate time estimate. To achieve the desired level of accuracy I’m going to try a few techniques.

Bottom Up - Considered an accurate method, bottom up sums small activities into larger units of work. Risks here are bad estimating of activities and too small of activities causing bloat.

Top Down - Estimate time for larger units of work, divide the time into the smaller activities that make up the larger units, and make any adjustments.

Analogous - Compare the Bottom Up and the Top Down estimate to completed, similar projects for accuracy. Risks here are differences in teams and forgotten issues that affected the project.

Hopefully by approaching the estimating process using three techniques accuracy will improve and validate the results. We’ll see.

I’ve always followed a traditional project management methodology, the Plan – Do. It fits my personality and it's how I’ve learned, but it rarely works well for clients or team members I work with and after years of trying to get other folks to follow this controlling project management style I have began to look for a better way. Agile methodologies may be that “better way”.

Let’s look at three basic types of project management. First there’s chaos and unfortunately this is how most firms I have worked with manage their projects. They jump right in and do things without proper planning, much control and little process. This is expensive and the main reason many web projects fail to be profitable and successful for the client. Secondly there’s Plan – Do. This is what most IT companies use. The idea is to plan everything out before development begins and hope to get it right and things don’t change too much. If things do, have a plan for making the changes then charge the client for the changes. Plan – Do is idealistic, resistant to change, not client friendly and difficult to manage. Thirdly there’s Agile which is an adaptive and flexible approach. Sounds good.

Agile differs in documentation, team participation and the project lifecycle. Jim Highsmith, of the Cutter Consortium and one of the founders of Agile, says planning and documentation should be barely sufficient. A lot of time is spent on planning and documentation. Perhaps this can be minimized.

Agile is based on short work cycles or iterations that deliver completed features all the while communicating with end users. When that set of features is accepted, on to the next iteration with the next set of features. The project is done in increments with approvals along the way. Plan – Do basically gets requirements in the beginning then builds the application and gets feedback at the end of a much longer cycle. Agile claims to eliminate a lot of the risk of acceptance because of the frequent end user feedback. Because of the feature based iterations, change is easier to incorporate into the project or at least change can be less expensive.

One key aspect of Agile is team participation. Team participation in planning and managing the details spreads the responsibility of the project across team members and gives them more ownership. That allows the project manager to focus on leading and communicating, the two areas he/she should be spending most of his/her time. Another example they suggest is allowing team members to choose what they would like to do rather than being assigned tasks and let people decide how they are going to handle those tasks rather than micro-managing development.

I recently became a certified Project Management Professional and learning that material seemed to solidify my conviction for the ol’ Plan – Do. The Project Management Institute’s guide to project management’s approach is very traditional, but can be adapted to Agile methodologies. The terminology is different, but the goals are the same: process and control. I have reservations about some things Agile advocates, but it all depends on the team and the project. The most import thing I will be exploring is to have a project management plan that fits the project and incorporates Agile methods where they might work better and get away from the mindset of only doing things one way and that is the PMI way.

Whether you’re a one person company, or large corporation, solid project documentation is good insurance. It provides a blueprint for the work to be done, serves as a valuable reference during the project’s lifecycle and is tangible evidence that communication has occurred.

There are several important pieces of information that should be part of any project’s documentation. On larger projects each may be its own document, or on smaller ones they may be combined into a few key documents.

The Proposal
 
This is probably the first thing a prospect or client reads. It’s the first written impression one makes and should set the tone of how one’s business is conducted. Often the proposal is a response to an RFP, or a meeting where a project was discussed and the work is not yet sold.

This is the time to communicate your company’s background, experience, and philosophy – the boilerplate stuff. It’s also the chance to envision how your company understands the project and perceives how the project is to proceed. Chances are there is not enough detailed information at this point to truly understand the entire project, or offer a final solution, but it can showcase creativity, intelligence and experience.

It is also not likely that a firm price can be quoted at this time. More requirements are almost always needed. An estimate with a price range is the best way to position costs. The cost estimate can be ballpark, plus or minus 25%.

Letter of Agreement, Contract

When the project is agreed to by the buyer and seller, it’s time to finalize that agreement with a binding document. A Letter of Agreement and Contract are two common terms used. This document should provide a project overview, terms and conditions of the relationship, any legal stipulations, and any high-level project parameters available at that time. It should also say whether any further documentation is being created at a later date that will be binding and part of the agreement. This document should require signatures by principal stakeholders from the buyer and seller.

Preliminary Scope, Statement of Work, Charter

The Preliminary Scope, Statement of Work and Charter are the second time the project is described if a proposal was written. There should be more information available since the work has been sold and the client has had a chance for more thought and discussion.

Content in this document should include everything known about the project:

• Description of services and/or products provided
• Business reasons for the project
• Benefits
• Constraints
• Risks
• Assumptions
• Success factors
• Stakeholders
• Sponsor
• Deliverables
• Cost estimate
• Timeline

On smaller projects there may be enough detail in this document to successfully describe the project, but larger projects require a discovery period to learn more, make conclusions and offer valid solutions.

Cost Estimate and Payment Terms

It’s a good practice to provide cost estimates with a range in the beginning and as the project gets defined better the estimate can be adjusted for accuracy. Plus or minus 25% is a good initial range with a final range being plus or minus 5%.

There are several acceptable ways to structure your cost. Here are a two common ones used in web development:

• Fixed fee – buyer and seller agree on a fixed price. This is good for the buyer; they know what they are going to pay up front. The risk is placed on the seller to complete the project within the budget.
• Time and material – Buyer pays an hourly rate for services plus the expense for any hard costs. This is good for the seller. They get paid for the time spent on the project. The buyer has the risk of exceeding the budget since it is difficult to calculate the cost at completion during the project’s lifecycle.

There are any number of ways compensation can be structured: half up front and half upon completion, thirds, all upon delivery, weekly, monthly and deferred payment. It depends on the nature of the cost structure. Use the compensation structure as a negotiation tool. A better overall price for a project may be attainable if the payment structure is favorable to the buyer. If the seller has cash flow issues they may get the needed money earlier in the project if the overall price is discounted.

Detailed Scope Statement

The scope statement could be the third attempted at describing the project fully and is the project blueprint. It is usually drafted after a discovery period when more information is available and needs to be as detailed as possible. When a scope dispute arises between the buyer and seller and the issue is not detailed in the scope statement the buyer usually wins.

Process
Describe the entire project lifecycle process to be used on this project, not the boilerplate version in the proposal.

Deliverables
List exactly what the deliverables are and include how many of what. Usage and ownership rights should be detailed too.

Parameters
Parameters are part of the requirements gathered from the client. They create the “box” in which the project resides. They can be technical and creative, dependencies, constants, guidelines and anything else that defines dos and don’ts.

Assumptions
Assumptions are often overlooked and can be a gray area if not noted. It’s easy to assume common things.

Examples:

• Access to resources – “access to servers”
• Extra expenses that may be incurred – “stock photos not included in cost”
• Responsibilities to handling related issues – “data is delivered in a spreadsheet”

Constraints
Constraints are things that are limitations to progress.

Examples:

• Time – “client may have difficulty getting timely approval on design”
• Financial – “funding may not be available for phase two”
• Technical – “network support not available”

Risks
Sellers often do not want to bring up risks, but it is wise to make clients aware of consequences that could occur if certain events happen. This is part of client education and expectation control. Making the client aware of risks also goes a long way to building a healthy level of trust. Detailing risks also helps justify certain expenses and processes required for the project that may not be apparent to the client initially.

Acceptance
It’s important to define what is to be considered an acceptable deliverable, or when the project is considered completed. Without this a project’s scope can creep when the client does not think all the requirements have been met. When defining acceptance refer to the quality and quantity of the deliverables and how acceptance is communicated.

Timeline

Often a timeline is created and the only person that pays attention to it is the person that created it. It is important to keep a project moving and to know when resources are required and a timeline is the best tool for accomplishing this. All parties should be accountable for adherence to the timeline and it should be approved along with the scope. Make sure the timeline has milestones denoted as well as responsibilities required at these important checkpoints.

Project Closure Agreement

Closure is as important as initiation. Formal acceptance is required from the buyer to this point. A Closure Agreement can be as simple as a payment in full, but better yet a document that states the project is ending and why: the requirements have been met and deliverables accepted, failure to deliver acceptable work, or buyer is terminating the project because of issues on their end.

If there is going to be subsequent work involved with the client, project closure provides a distinct division of services and can help when communicating what was covered in the completed project and what is new work to be done.

Conclusion

As a project progresses more information becomes available and requirements may change for a variety of reasons. It is certainly acceptable to revise and update any document that is no longer valid. It is nearly impossible to have perfect documentation right from the start, especially on larger projects. There should be a process in place for making and approving these changes. This change control process could be outlined in the Scope Statement just as scope control would be.

There is much more to project documentation than what is touched upon here, but hopefully the importance of proper paper work is obvious. The cost to document a project properly is nothing compared to the cost of confusion and arbitration when things get ugly and the client relationship turns south. It is protection for all parties and is indicative of handling business in a professional, competent fashion.

When discussing site design and technology with clients, we always discuss the use of Adobe’s Flash technology in the site. Adding Flash can give a site a tremendous visual kick:

• Smooth, slick navigation menus
• Controlled page loading and transitions
• Motion graphics, sound and video
• Increased control over design and especially typography

Flash can also accommodate functionality that cannot be achieved as well using other methods:

• Application interfaces that require variable graphics at run-time
• Remote calls to the server without page refresh
• Dynamic navigation menus

Some Considerations

Before using Flash there are some considerations to make. Flash introduces additional technology to the site architecture that requires the Flash Player Plug-in to be installed on the user’s computer. While Flash has considerable market penetration, over 90% for version 7.0, this still may present accessibility issues. The newest version of Flash, version 8.0, has significantly less market penetration.

Flash can also affect usability. When a site is built as one Flash movie in one web page, the browser’s back button is useless for returning to a previously viewed page in the site. This can be compensated for by additional programming, but most sites do not fix this usability issue. Building a site as one movie can also create a large initial load time. Some developers handle this gracefully with clever loaders, but this still makes a user wait.

Flash is more expensive to develop and more difficult to update. Animation sequences require a lot of man-hours to create and are subject to more revisions by clients because there are more details to criticize. Flash movies are compiled files, they cannot be directly edited. One must edit the source file and recompile the web formatted movie. This can be a real pain if you have other resources work on the site. Source files can be lost and fonts may not be available, making editing problematic.

Flash is often the best solution. Here are some useful benefits of using it in a site:

• If user experience is a big part of your site, nothing is better than Flash for creating awesome experiences. Cutting-edge sites combine interactivity, sound, and TV-like video presentation capturing the users’ attention.
• With all the recent hype about AJAX, Flash has been capable of making remote calls to the server for years. Rich Internet Applications provide great usability and experience.
• Flash is often more browser compatible for interface interactivity than DHTML.
• Displaying video as Flash is better than having a Windows Media Player, Real Player and QuickTime versions with the need for their respective player plug-ins.

Each version of Flash gets better with more features. ActionScript, Flash’s programming language, is more robust than ever. The seamless incorporation of video is revolutionary. As more users have the Flash Player plug-in, always consider Flash.

Benefits vs. Cost

When gathering requirements and planning a site, measure the benefits compared to the cost. Here are some specific requirements to consider:

• Will users have, or be able to install the Flash Player Plug-in?
• Is Flash going to create a technological roadblock to content within the site?
• Is Flash adding something special that cannot be done without it?
• Who will be making edits to content in the Flash movie(s) and how often does that occur? Flash can be developed to load data from external files which may overcome the need to recompile the web movie files. This should be considered if updating is a requirement.
• Do other developers working with the site have the necessary experience to successfully integrate and maintain the site containing Flash?
• Is the budget sufficient to create and implement Flash correctly?

Sometimes using Flash makes sense and sometimes it doesn’t, but one thing’s for sure there are more Flash sites than ever before and that trend isn’t going to change.

It seems data security is becoming a big part of the projects I work on. Identity theft has demanded increased security measures for the storage and transportation of personally identifiable information (PII). PII can include name, country, street address, e-mail address, credit card number, Social Security number, government ID number, IP address, or any unique identifier. The American Institute of Certified Public Accountants (AIPCA) and Canadian Institute of Chartered Accountants (CICA) have created an extensive privacy framework that a lot of companies are adopting. The Payment Card Industry has also created a Data Security Standard based of requirements developed by VISA, MasterCard, American Express, Discover and JCB. These standards and requirements affect e-commerce, travel, authentication, human resources, medical, and other similar applications on web sites, intranets, extranets, other client server and legacy systems.

If your current, or next project collects and processes PII data, do yourself a favor and find out the requirements and necessary steps to meet them. Many of these requirements are fairly new and changing. Clients may not event know them, but if something happens and losses occur, as creator, or administrator of the application you could be liable.

While watching Bela Fleck the other night, I was thinking about how precise and structured the music was yet organic and improvisational at the same time. This balance is the core of a good jam and exemplary of building a good web site. There are logical, learned aspects and emotional, intuitive ones. In web development project planning, database design, programming, and testing are usually the methodical parts while the graphic design, content creation and rich media are more exploratory. My favorite aspect of web development is the blending of technical and creative activities into one homogeneous entity. The better this happens, with careful balance, the better the results.

Both technical and creative people can learn from each other. Technical people thrive on structure, but when creativity is added amazing things can happen. The opposite is also true for creative folks. Applying structure to their process can allow them to concentrate on being creative while maintaining uniqueness to their approach. Technical folks can improve their problem solving skills by approaching tasks in new ways. Try having a developer learn a new programming language, or code something by hand not using the software they usually use. Creative folks may be able to improve hard skills such as using complex software and networks. Have a designer work with someone who is organized and efficient. Pair a creative with a technical person to share knowledge. Learning to be proficient within one's working environment allows them to concentrate on the core problem at hand. Being independent of one’s crutches fosters original thought. Different perspectives result in different solutions improving overall team performance.

I was involved with a project last year that brought to light a major decision that needs to be made early in a project’s initiation.

Do we build onto our existing application, or start from scratch?

As developers we always would like to start with a clean slate, but web projects are often part of ongoing operations and legacy systems greatly influence the how they are planned. There are times to extend systems in place and times to begin anew. Too many times companies throw good money after bad. Let’s look at some things to consider.

How Old Is It?

Spend resources to maintain systems first. If the platform, application, database, infrastructure or hardware is deprecated, or even a few versions old perhaps it’s time for an overhaul before thinking about adding onto it. Whether it’s lack of money, downtime, or human resources it's important to keep your core systems up to date. Technology changes fast. If too much time passes between upgrades it is more costly and difficult to bring things up to date.

How Compatible Is It?

The system should still have significant market share. One year Sun as the best solution and five years later Microsoft is the market leader. Software manufactures are making compatibility improvements with every version, but interoperability may still be difficult to achieve. It makes little sense to spend development dollars on utility software to connect outdated or obscure systems with new ones. This adds tremendous costs to project budgets and the problem still isn’t fixed. It’s impossible to predict the future, but try to choose a platform that will be around.

Does It Suit Your Needs For The Future?

Never build something for today, build it for tomorrow. By the time a project is finished it may already be outdated so it is important to build ahead, or at least plan ahead. Your web server may handle the load today, but what happens when your company doubles in size, or you want to add e-commerce?

What Are The Alternatives?

It may not be necessary to abandon the system entirely. Upgrading to the current version may be enough. Are there products offered that are clearly better for your needs, or are there more cost effective solutions? Should I build, buy or lease? Do due diligence. Explore options. Compare solutions. It takes work to make the best decisions. The less expensive route now may cost more in the long run. Get help doing the homework and making quantified analysis. It pays to put off a project to do it right rather than making this situation worse by employing any less than best practices.

A conversation to have with clients during the planning phase of a project is whether, or not to have a content management system (CMS) for all, or part of their site versus having a maintenance agreement to make updates. It grossly affects the budget and it has an impact on the relationship with the client - pay upfront for the CMS, or pay over time for service. A good rule of thumb is, if content is not updated more than 4 times a year don’t get an administrative tool for it. The idea of the ongoing relationship with the maintenance agreement can be a good thing. It almost always grows into something better than just maintenance.

A scenario that happens all the time is a client thinks they need a content management system (CMS) so they can update the site themselves and save money. A few weeks pass and they call to have the vendor make updates using the CMS system because they don’t have the resources to do it, or need something fixed they messed up. In this case they pay twice: once for the CMS and once for the update labor. No money saved there.

Whether it’s a designer or client making the changes, a web site evolves. It’s one of the benefits of the medium. It’s important to plan how a site’s content is going to change. Decide what control method meets client needs, has the biggest impact on budgets and ensures the site remains effective.

The client relationship is the single most important part of any project. They are key stakeholders. Yet, it is often the most under managed part. A good client-vendor relationship is like a good person-to-person one, but many businesses do not treat it in this respect.

Would you like fries with that?

How many times have statements like these been said?

“The client is always right.”
“Just give them what they are asking for.”
“The client said to….”
“All they want is…”

Many companies preach to their sales staff “Excellent service is our business.”, but for some reason the term, “service”, is embodied into sales people becoming glorified order takers. This is bad. It’s bad for the client; they do not get the benefit of the vendor’s expertise. It’s bad for the sales person; they are unable to truly gain the client’s respect. It’s bad for the people actually creating the work; they get forced into producing substandard work and doing a lot of rework which is very frustrating. It’s bad for the management; they loose control of a project.

Jerry Maguire Rocks!

“Help me help you.” Truer words were never spoken when it comes to providing service and helping your clients succeed. Like a healthy person-to-person relationship where there’s communication and respect, and both are the better for it, the client-vendor relationship should be the same.

Sales people please take note. You will be far more successful by managing your clients rather than allowing them to manage you. The approach to take is to assume the role of the expert, establish the ground rules of the relationship early, manage expectations, and communicate openly and honestly throughout the entire project.

Being the Expert

By assuming the role of an expert the other aspects often just fall into place. If your client won’t play this way don’t do business with them, or charge a premium to put up with the added stress, but with the latter you have already really submitted and have lost a great deal of leverage.

Expert behavior wins business. The cutting-edge shops producing the best work have it. It’s not arrogance, but an approach that adds value by becoming a partner with the client.

Expert behaviors:

• Be a teacher. Teach your clients what, why, and how.
• Understand the clients’ perspective and make sure they know you understand it.
• Make sure they understand your perspective and why you have it.
• Have a process and stick to it. Explain the importance of process and how it will produce the desired results and save them money.
• Over communicate. Explain everything thoroughly. Make sure clients understand why it’s done that way and what the consequences are for not doing it that way.

Manage the client with the same effort as managing other aspects of a project. The relationship will be stronger. The work will be better. Your team will be happier. You and your company will make more money.

I often have to decide what techniques or technologies will be used to build a site. Some are defined by the project's requirements. Others can ALMOST be arbitrarily made. Examples include databases, MySQL or SQL Server; whether or not to include Flash in a site and to what extent; developing a data access layer or use single tier architecture; or should a table HTML structure or layers and CSS be used.

I can appreciate the benefits of no tables and separating content from formatting, but I have a few issues with the standards compliant way of doing things:

1. There are no real standards. Therefore it’s almost impossible to build a site with any interface complexity that will view correctly in an acceptable percentage of browsers or situations. Table layouts are pretty much bullet proof.
   
   
2. Time and money - If a standards site is done correctly and does view in all required browsers chances are it took a lot longer to build than if tables were used. Does the benefit outweigh the cost?
   
   
3. Development resources - The one prevalent factor I always consider is who needs to work on the site in the future. It is important deliver a site for which a client can find development resources when changes are needed. I have experienced a couple times when a site was delivered that was too complex. Not only are the user's technological limits a factor, but the client's technological limits can sometimes also be a constraint.
   
   We once built a killer site with a dynamic content and Flash and within two years the client had a simpler one built because they wanted an intern to be able to make changes using Front Page. (shudder) We were not told this at the time. Another experience was we built a really nice interface for a web app in layers. When it was handed off to the development team they did not know how to make it work with the dynamic content as they said they could. We had to redo the layouts in tables.

The point is, in a perfect world the idea of compliant sites with clean separated code rocks, but the reality is, it's often not practical. Cutting-edge (scary that I'm calling techniques that are several years old cutting edge) always has added risk. Careful consideration must be made before choosing any technique. Rework is too costly.

 I recently became a member of the Project Management Institute, PMI, and certified as a Project Management Professional, PMP. It was a difficult test, but well worth it. Many employers and clients are requiring this designation or at least seriously favoring it. The information on the exam is very useful and can be applied to all kinds of business situations. It has surely made me a better PM and business person.

I used online training at PMCampus.com to get the required 35 hours of education. The price wasn't too bad and they had the information covered. My only complaint is the poor graphic design and usability if their site and printable materials. Ugly!

How does one decide whether to buy a packaged solution or build using custom development? Which one will deliver the best results most economically? Each project is different and sometimes either methodology will suffice. This article hopes to shed some light on the underlying reasons for choosing one direction or the other in web development projects.

Portals, shopping carts, content management systems and intranets to name a few, can be purchased, installed and configured in a fraction of the time and cost it would take to build them from scratch. In the past few years there has been a huge shift in how Web application development is marketed and sold to customers. It has gone from primarily custom development services to packaged products. Every technology company has a brand and a product to sell. Often these products begin as a custom developed solution for a specific client then the firm decides they can resell their experience and resulting code. This has three primary benefits to the firm: bigger profit on reselling the same work, generated revenue of customization of the product, it’s easier to for sales people to understand and customers are often more comfortable with purchasing something off-the-shelf. The perception is there is no need for expensive programmers; less risk, better support and upgrades are available. All these reasons are assumptions and may not be true.

Evaluation

Purchasing software is just like purchasing anything else. The quality of a product is only as good as how it has been designed and constructed. There are hundreds of inferior software products on the market that have been purchased by millions of customers. Even leading software manufacturers like Microsoft and Adobe release products that have major inherent flaws.

On the other hand, customers are often aren’t qualified to audit the practices in a custom development project. A demo is done and if the application passes quality testing, it is accepted. Only when another developer looks “under the hood” is when the realization of the quality of the design and construction is revealed.

Let’s define some of the criteria for quality and acceptance of an application:

Performance - Performance is a measurement of speed, reliability, usability, maintainability and how well an application meets business requirements.

Often the packaged solution has extra features that are not part of the requirements of a project. The product is of better grade, but not necessarily better quality. These unnecessary features add to the complexity to the application increasing development expenses, and may consume resources, reducing the overall performance of the application.

Functionality that is essential to the project’s requirements may not be met exactly by the application and this may be costly to alter. Work-arounds and hacks are sometimes used to “just get it to work,” jeopardizing the integrity of the software’s design and performance making it extremely difficult to troubleshoot and modify later.

Business rules may need to be adapted to match the application’s functionality when the opposite is the goal and adding to the scope of the project. Software is supposed to enhance business practices not require them to be changed.

Implementation - Speed of implementation and integration is one of the biggest selling points of packaged solutions. Customers think since it’s already built it must be faster to get in service. This is mostly true and one of the best reasons to use a packaged solution, but in situations were there is integration with existing systems, interoperability problems could stop implementation in its tracks.

Just because the manufacturer said it would work doesn’t mean it will easily or completely. Many times custom developed utility applications are required to connect disparate applications adding to the complexity of the overall system. Specialists intimate with the product are required to provide analysis and uncover the unique way it may work.

A big issue when a project calls for several products to function together is the number of vendors that may be involved. Vendors look out for themselves and when things don’t work as planned the finger pointing starts. Passing blame and not working together will kill any schedule. It is best to limit the number of vendors and have a non-biased project manager not focused on selling you something keeping the project on track.

Expense - Customers are initially seduced by the price of the product itself, but may find themselves paying more. Costs may be upgrades in infrastructure, helper assemblies, and utility software requiring customization by specialists. These costs can quickly become the majority of the total cost. Non-required functionality that comes with the packaged solution may also increase the cost of the product.

Support - Customers feel packaged solutions provide better options for support. This may be true or not. Products get discontinued everyday. Technologies are no longer supported. Resellers go out of business. You cannot count on having the company that you purchase from around to provide service.

The key thing to emphasize is -- it’s not whether the solution is a packaged or custom application, it’s how well it is designed and developed. If the application is built using standard technologies and best practices it can be worked on by any competent professional programmer skilled in those technologies. The caveat is the availability of that resource.

Growth - Both packaged and custom applications can be built with an open architecture that provides access to functionality. Object oriented design, APIs, and Web services all add to the ability to grow and adapt over time. If this is a priority, make sure your application can be scalable and extensible. It may cost a bit more up front but the savings will be huge when time comes for change.

Keep It Simple

Perhaps the best of both worlds is using pre-developed components, assemblies or libraries that provide small units of functionality for custom development. The application can be designed to meet specific requirements. Unnecessary functionality and bloat is kept to a minimum. Best practices can be adhered to. Timelines may be decreased and the support network is increased while not adding to the number vendors or developers directly working on the project. These “mini products” enable developers with lesser experience to create complex applications by following guidelines. They leverage the skills of senior developers and give a great boost to development practices. There are whole modular systems and frameworks in a variety of platforms like ASP.NET, PHP, and RUBY and JAVA. This is a huge area of growth and an exciting direction for custom development.
 
Get Help

Custom development is not nearly as expensive as it was a few years ago. Rates have dropped as competition has increased and Rapid Application Development techniques are improving productivity. Having a properly designed and developed custom application means less code, easier debugging, better performance and an overall simpler piece of software. As with using a packaged solution, make sure your custom application is designed using standard practices, is easily extended, has the source code and development resources are available when it’s time to make changes.

Custom development may not be the answer. Sometimes your site needs is a component and there is a product that will suit your needs perfectly. Packaged solutions excel in smaller, independent applications. They can often be purchased, installed, configured and in service much cheaper and faster than custom development.

Before making the purchase of a package solution make sure the product meets your requirements or can be altered easily to do so. Find out costs hidden in the extras that are needed. Get estimates on custom development for comparison. Think towards the future. Research resources available to provide support and maintenance. Complete due diligence and then you’ll be able to make a sound decision.

There are more alternatives to developing a Web site today than ever before. It is difficult to wade through all the latest information. Products take time to research and a good vendor is hard to select. Working with a good Project Manager to guide the decision making in the best interest of the project is invaluable. Just remember there is no best solution. Each project has its own requirements. Explore all options.

There are several common issues many marketing and communications firms share when trying to offer interactive services to their clients. While the general topics below encompass a lot of the problems that happen to some degree in both large and small firms, they certainly are generalizations. And if your firm has any interactive experience they may be familiar – but hopefully not too familiar.

1) Sales Anxiety

Most sales development and account management personnel have not had as much experience with interactive media as with print and broadcast projects. Often this unfamiliarity creates anxiety, making it difficult to sell these services effectively. If a company’s sales force cannot speak comfortably about interactive, it is very difficult to gain a prospect’s confidence and make the sale.

Anxiety is also caused by lack of confidence in a project’s outcome. The foremost fear is failure to produce successful work. A firm can create award-winning design, or prove amazing marketing results, but if a sales person isn’t sure of what they’re selling, or positive their company can delivery a quality product, they hesitate to show a possible weakness to a prospect. No one wants to jeopardize existing client relationships or mishandle a potential new piece of business. As a company owner or sales director, don’t put sales people in this position. Get access to appropriate resources that support an adequate selling process.

2) Unfamiliar Territory

By its nature, interactive has distinct differences from the traditional services provided by communications firms. The primary difference is the underlying use of complex computer technology that neither sales people nor prospects may fully understand. Two options present themselves: train your sales people to present interactive capabilities effectively, or supplement the sales effort with someone who represents interactive.

If hiring a liaison for your interactive department sounds like overkill, let’s compare technology to creativity. Sales and account people rarely articulate the meaning and nuances of design and creativity effectively. For this reason the Creative Director’s role has been to represent these disciplines to clients. More often than not, an agency does not have someone like a Creative Director in place for representing interactive technology, so you may be missing the “link” that your firm needs to effectively communicate interactive to prospects. This person can have many titles: Director of Interactive Technology, New Media Director, Interactive Producer, or Interactive Project Manager.

Good sales efforts require a compelling story. Make sure you have a good story and your sales people understand why it has value. Define the capabilities and services you intend to provide and create a vocabulary that prospects can relate to and understand. The biggest mistake is trying to be everything to everybody by constantly changing position, offerings and capabilities. It prohibits sales people from having a consistent game plan and gets them out of their comfort zone.

3) Inaccurate Estimating

Poor estimating will either cause a net loss on a project, or price the work out of line with what the prospect will pay. Prices are quite varied, but in general are not what they were four years ago before the dotcom market collapse. Interactive is not new anymore, and basic economics have driven down values.

To determine how to price your interactive projects, consider the following:

How much will it cost you to produce the work? The lower this number the more competitive your pricing can be. This is no different than pricing any other type of work except there may be new services and products required to produce interactive projects that need to be researched: software, outsourced specialized skills, leased services, licenses, and more.

What differentiates your work from others? Is it killer design, proprietary technology, or rapid development? Are you selling services or products? Make this part of your story and reflect it in your pricing. However, if you cannot explain your differences and justify how they are priced, it will lower your chances of winning projects.

What’s the value of the project to your prospect? This value may differ drastically to different prospects. So research your prospects. Do they like using local vendors only? Do they shop around and get several bids for projects? Do they have a reputation for working with inexpensive, or high-end vendors? Are they demanding, or easy to satisfy? Is there opportunity for future business?

Be aware of the client’s perspective. For example, if you offer outstanding Web design and they don’t value it, they’re not going to recognize that value or be willing to pay extra for it. Knowing the prospect’s personality will help you determine what should get emphasized and minimized when estimating and selling the project.

Estimating proposals for projects with fixed budgets is another common scenario. It’s almost an opposite exercise than assigning prices to a project. Can you meet all the requirements and stay within budgetary guidelines? This process quickly exposes whether operating and production costs will allow a profit. It is important to meet all the requirements to some degree, but you may not be able to deliver all the bells and whistles. Use the prospect’s personality as a guide to determining what gets the most attention in your proposal.

4) Ineffective Project Management

Project management directly affects the bottom line. The term project management is used here in a broad sense: It begins with setting client expectations and doesn’t end until you deliver the final product. As a project progresses, production must be efficient as possible to keep costs to a minimum – especially with a tightly estimated price.

The number one reason for unprofitable interactive projects is changes during production. Changes are very costly and the client rarely feels they should pay for them. Interactive differs greatly from print media regarding changes. Technology is a building process. During development each step is dependent on its predecessor – similar to changing the floor plan once the walls are in place when building a house. A change may require reverting back several steps to accommodate it. It is very important to communicate to the client at the beginning of the project the implications of making changes too late in the production process, and to establish who will be responsible for cost overruns caused by changes. Defining the project’s scope, detailing deliverables and scheduling accurate timelines are all important to limit the liability of project changes and excessive expenditures.

Remember; project management is not one person’s responsibility. It can be dependent on the account manager, producer, project manager, lead designers and developers, and the whole team. Proper communication and coordination is crucial for success.

5) Insufficient Resources

Having appropriate resources is good risk management. It affects everything involved with getting and producing good work. This is not different from traditional media, but it requires different human, technical, and logistical resources to produce interactive projects.

Interactive requires skill sets that may not be familiar to communication firms’ human resources departments. Whoever imagined agencies would need programmers or database administrators to service client needs? The introduction of these new skills creates a myriad of issues. The people you’ll hire require different equipment to perform their duties and often come from a different occupational culture. It is a challenge to make this all work and is a big reason why production is often not efficient enough to be profitable.

An important question to ask is whether to hire or outsource. Each option has inherent problems. Staffing is expensive to maintain. Outsourcing can be unreliable. Each company must complete due diligence while deciding the best approach. The important thing to remember is to have good human resources and plenty of options. Know the risks and weaknesses of each source. Don’t be caught short.

Another important production cost saver is having the proper infrastructure to produce interactive projects and have standard operating procedures in place. Talented people cannot do their best work if not provided with the proper tools of their trade. Not having these essential tools creates time bombs that explode at the most inopportune times. Breakdown of processes at critical times can make your company look bad, and undermine your best intentions. Infrastructure is expensive, but not as expensive as wasted weeks of production, producing a poor end product, or even a losing client.

Can You Afford Not to Seriously Pursue Interactive?

It is becoming harder to be competitive by not offering interactive services to prospects and clients. Interactive is not going away and can be a profit center if it is approached intelligently and integrated into your core business offerings. Having adequate resources, good project management, accurate estimating all support the sales effort, resulting in positive results for your company in interactive development. I can provide the expertise to increase your capabilities, the resulting sales and realized income.