The Iron Triangle allows for only two factors in determining the success of a web project. But the impact of the client’s perspective on the triangle seems to reduce the two factors into a single option.
Early on in my development career, I leaned how the Iron Triangle impacts projects. The iron triangle (aka the Project Triangle) is a software development concept that says that the quality of a project is determined by three factors:
- Timeline. How long you have to complete a project?
- Budget. How much is the client is willing to pay for the work?
- Features. What functionality can be built?
The point of the Iron Triangle is that you can pick or constrain only two of these three factors. So if the project timeline and features are constrained, then the budget must grow. If all three factors have to be met, then the quality of the web project will be sacrificed. While this concept seems to give developers some breathing room, the Iron Triangle seems to be further constrained when the client’s perspective is taken into account. Let me explain.
A client typically approaches web projects with two constraining factors. When a client requests a solution, they normally constrain the project by asking that the solution be delivered by a certain deadline. The deadline is normally set because the client needs to meet a pre-determined objective, such as seasonal promotion, customer acquisition campaign, etc. Additionally, when a client requests a solution, they further constrain the project with their budget. Since money doesn’t grow on trees, the client will dictate how much they can spend for development on a project to be completed.
So when the client’s constraints on a project are taken into account, the Iron Triangle is actually reduced to a single option: project features. This means that developers have to look at how many features they can implement for the time and money that they are given. The good news is that the feature list can be functionaly robust or weak. That means that there’s some play in what the client will or will not get for the time and money that they’re dedicating to the project.
Understanding the purpose of a legacy microsite can help you determine whether you should fold it into your newly designed website or dump it. These tips will help guide you in the decision making process.
In my tenure as a web manager, I’ve worked on countless projects where the client wanted to redesign their website. The first step in a site redesign process is to complete a site mapping exercise, where various pages and content are identified. As part of the process, we frequently uncovered microsites, which is somewhat like finding a skeleton in the closest. The newly found microsites raise the question of whether they should be collapsed into the site or permanently removed.
While answer may seem elusive, I’ve found that the decision can be driven through thinking about the common characteristics of a microsite. These characteristics include:
- Unique branding
- Special content
- Custom navigation/URL
- Nonstandard content management
To clarify, a microsite is typically launched to support a new marketing initiative or promotion. The site may break the branding guidelines or rely on new print collateral so that the marketers can fully test their initiative. A microsite frequently has new content that doesn’t follow the normal content structure of the website. Additionally, the microsite may play a part in an SEO campaign or and SEM campaign so it may not link to the corporate site or require custom navigation so that visitors don’t have to think. Lastly, the content on the microsite may require more involvement than the corporate IT department can dedicate to this initiative.
So how do these characteristics help determine whether to migrate the microsite?
To answer this question, one must simply evaluate whether the characteristics of the site when it was built have stood the test of time. Some questions to ask yourself include:
- Has the marketing initiative or promotion become a permanent part of your marketing offerings?
- Can the design shift back to the corporate branding guidelines?
- Can the content fit within the corporate website through the use of an existing content template?
- Will the microsite continue to meet its goals if the navigation matches the corporate site?
- Can the content on the microsite be managed through a Content Management System or CMS?
By answering more of the questions above with a yes, the clearer the direction is to fold the microsite in with your website.
In my previous post on online forms and project requirements, I discussed what can happen to data once a form is submitted. And while it is critical to understand what happens to the data, web developers developers also need to better understand the form data.
As defined in the previous post, an online form is an interactive interface where a user can submit one or more fields. The fields allow a user to submit data, where it can be their name, email address or even password.
There are two general types of fields:
- Free-flowing fields. Often referred to as an input field of type TEXT, these allow a user to enter virtually any kind of data, including alpha numeric text, dates, or numbers.
- Constrained fields. Often referred to as a SELECT field or an input field of type RADIO or CHECKBOX, these allow a user to enter pre-determined data.
Once a user enters information into a field, the field can be validated to ensure that the data is of the expected type (IOW, an email field gets an email address and not a first name). This is often referred to as a required field or a field that must be filled in order for the online form to be submitted/data to be accepted. There are two types of form data validation:
- Server-based data validation is the ability to use the web server to validate the data once it is submitted to the server. This validation often relies on a server-side scripting language, including ASP, ASP.NET, ColdFusion, JSP, PHP, etc.
So based on the above, project management should collect the following requirements regarding form data:
- How many fields will appear on the form and what type of data will be submitted through each field?
- Will the form require any validation and will it require client-based or server-based validation?
- If validation is required (regardless of type), which fields will be validated and what is the expected data per field?
- If server-based validation is required, what kind of scripting language will be used to perform the validation?
These questions should help you round out the online form requirements gathering.