Storm Code

Content is the most important part of any website.  It can be the text, audio, video and images that appear on each page.  At a very basic level Web Design can be broken into two different parts.  On one side you have the development of the actual pages, be it HTML, JavaScript, PHP, ASP, AJAX, Ruby on Rails, etc.  On the other side you have the creation of the Content.  Most Web Design companies handle only the first part which is the development of the actual pages.  It’s usually up to the Client to develop the content that will appear on the pages.

Content can be a HUGE bottleneck.   At different times during the development of the actual code for the pages, Content needs to be taken into account.  That is why creating the Content for a website before hiring a developer is a great idea.  It allows the developer to take into account the Content when designing the web site or web application.  The Content that is provided to the web developer should not be considered the final copy.  It’s just a guideline that the developer can use to better create the site.

It also means that the Project Managers on both side (client and developer) do not have to go back and forth as much with regards to the content that will be appearing on each page.  The client will not need to scramble to create content that the developer needs in order to continue or finish development of the site.  When the project leaves the design phase and the web site or web application has been tested, the client won’t need to begin creating the content at that time.  This means the web site or web application can be released sooner.

Many times, the Client does not take into account that actual Content that will be appearing on the web site or web application until the entire development of the site has been finished.  As stated above, this means that the release date of the project has to be pushed back while that Content is created.  This can lead to poorly thought out Content.  The Web Design company should be offering the Client suggestions about the Content.  It should be optimized for Search Engines, and it should be as jargon free as possible.

Jargon Free.  That’s a very important part of content.  When writing Content for a website you want to make it as simple as possible.  The Client knows and understand the business they are promoting but that does not mean that the users that come to the website will understand.  Web sites exist whose Content is full of Jargon and overly complex text that can confuse the user.  In some cases a dictionary of terms is provided somewhere on the web site or web application to help new users under the Jargon.  If you find yourself needing or thinking about a dictionary of terms, then you are using Jargon.  A dictionary of terms is almost an afterthought to make up for badly thought out Content.   As with any rule there are always exceptions.  If Content is being designed for a specific audience, then using Jargon may be the necessary, as it would be if you were writing a technical document.

Writing good, thought out, jargon free content is just as important as having a well designed web site or web application.  It’s just as important and as having a site that is optimized for search engines.  It’s as important as any other part of designing a good web site or web application.  It should get the same time, planning and effort that the other aspects of web design and development do.

Creeping Functionality, also known as Scope Creep is often described as “Death by a thousand cuts.”. It occurs when new functionality and features are constantly being added to a project that is already in progress. It can increase cost, push back the completion date, and severely damage development strategy for a project.

How does Creeping Functionality occur? After the Information Gathering phase of a project is completed with the Project Specifications and/or Proposal having been drafted and a contract is signed to develop and complete the project. During the Development Phase the client asks the Developer to make a negligible change. The change is so small compared to the entire scope of the project that it doesn’t seem to warrant a Change Order. These changes pile up during the Development Phase and after awhile the full scope of the negligible changes becomes apparent. The idea of writing twenty or thirty or a hundred change orders to account for the total time spent on changes outside the scope of the project becomes in and of itself a daunting and time consuming task.

Why does Creeping Functionality occur? One of the reasons that Creeping Functionality occurs is improper scoping of the project during the Information Gathering phase. Features and Functionality that are considered important were forgotten or not conceived during the Information Gathering phase and are now trying to find their way into the project after a contract has been signed.

Another reason that Creeping Functionality can occur is perceived value. Everyone wants the most bang for their buck and will try to slip in added functionality or cool features that will raise the perceived value of the finished product. At times individuals that were not involved in the Information Gathering phase of the project will begin to take an interest in the project and attempt to interject their own opinions and ideas into the project scope. Developers want to keep the Client happy and making small changes that allow them to look flexible can be a persuasive path to take. However, it comes at a cost.

Creeping Functionality can go unnoticed by Project Managers on both sides of the ball until budget and scheduling problems arise and bring the problem into the light. The budget can increase exponentially as hours worked on features and functionality outside the project scope pile up. Those hours that should have been spent on building the features and functionality inside the project scope push back the completion date of the project.

This is where perceived value and actual value come into play. It’s great to get the most out of your money, but at what other costs? Is the actual value of adding a negligible feature to a project more then having the project completed on time and within budget? The answer is a resounding no.

Creeping Functionality also taints any Development Plan that was put into place in order to keep the project on schedule and within budget. It divides developer/client attention between completing the project as defined by the contract and making the website as cool and feature packed as possible. It can be overwhelming and also cause tension. It can be very hard for a developer to say no to making a small change, and hard for a client to understand why when the developer does say no.

Managing Creeping Functionality is a very important part of Project Management. Getting the Project Scope right the first time and regular reviews of the Project Scope can keep it under control as to prevent problems.

It is important for both the Client and the Developer to be aware of Creeping Functionality and how to prevent it. At Storm Code we use a phased approach to development that can not only help prevent Creeping Functionality but also increases Actual Value, as opposed to Perceived Value.

Consider the original features and functionality of the project to be List A. Any features and functionality that were discussed during the Information Gathering phase that were seen as unnecessary or outside the current project scope, budget or time line are added to List B. List A has a deadline and a budget. After the deadline the website, or web application is released and the client makes it known that they have a new website or web application and people begin going to the site to check it out. This results in exposure, sales, leads, and much more. If Creeping Functionality had been allowed into the project then the release date would be pushed back and that exposure and everything that goes along with it would not exist.

List B consists of everything discussed during the Information Gathering phase that was not inside the original project scope, as discussed above. List B also consists of all the features and functionality that were thought up during the Development phase. In other words, all of the Creeping Functionality that could have effected the budget and time line. List B is considered to be Phase 2 of the project. After the website or web application is released, work on Phase 2 can begin. A new project proposal is drafted and contract signed. A new deadline and budget is created and work begins again anew. When the Phase 2 project is completed the Client can then spread the word that their website or web application (that is now no longer considered new) has some cool new features and functionality that everyone should come check out. If everything had been piled onto List A, it’s possible that the original project may not even have been completed by this time, and if it had, that would be it. No opportunity to invite users and potential clients back to the website or web application because no new features would be coming along.

A website or application is a marketing tool and nothing speaks better about a company or individual then if they keep their website or application up to date and constantly evolving with new, thought out, features.

For more information on Creeping Functionality please read this article by Steve Holder How to Keep Scope Creep from Sapping Project Profit