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.

A good interview of Todd Purgason from Juxt Interactive on Lounge72 re-published from Encore magazine.

I was browsing a site this morning and wanted to see the source code, which I often do, and quickly found out I could not access it, nor could I save the page. Wierd. There are ways to control, by script, the right click menu, but this was different and prompted some Google research. I came across HTML Protector. It looks like a neat little utility. One of the best features -- it prevents email grabbers from lifting email addresses from web pages. Nice.

All JavaScript Rich Text Editor.

http://tinymce.moxiecode.com/

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.

Hirshhorn Zuckerman Design Group - just good work.

Came across a new web design/dev site with some good contributors and articles. Vitamin is a resource for web designers, developers and entrepreneurs.

It seems search engine optimization (SEO) is on the forefront of every web site owners mind -- the holy grail of getting visitors to their sites, or so they think. SEO companies are in high demand. Here's a site with a wealth of current, useful information on the topic.

Internet Search Engine Database

Digg is a technology news website that combines social bookmarking, blogging, RSS, and non-hierarchical editorial control.

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.

Juxt Interactive, innovative with design and technology.

Here's why:

Nestea Ice and Just for the F of It,

Can you take a simple list and use different Cascading Style Sheets to create radically different list options? The Listamatic shows the power of CSS when applied to one simple list.

There are also examples for using float and selectors.

http://css.maxdesign.com.au/listamatic/

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.