5 stages of project management

BT Tower, London

Web development requires a structured project management

This is the first part of a series of posts detailing how Redcentaur manages web design projects for its clients. In this post is an overview of the five stages we use to develop web sites. Detail will be provided in future posts that link each of these stages together.

While steps used within these stages may vary widely from project to project, and depend largely on what is involved in each project, the stages themselves generally remain the same. This is because they are fairly generic in nature. However, do not underestimate the importance of good project management skills: they can save you and your clients money, time and unnecessary effort. Vandelay Design has identified 10 other basic principles for projects in the excellent post, Guide to finishing projects on time, which supports this series of posts quite neatly.

The one most important factor for project management is communication.

No project management post would be complete without mentioning the one most important factor for project management: communication. It is essential for any well-executed project for the project manager to talk to the client, the design team, the development team and anyone else involved in the project. If there are relatively few people involved, this becomes easier, but it is essential that the client and the team working on the website are in communication.

Two kinds of project management

Redcentaur uses a flexible approach to project management, which is based on the kind of project we are working on, the particular needs and structure of the project and the client we are working for.

Structured, hierarchical approach

With a cascading or “waterfall” approach to project management, each stage of the project, from Inception through to Completion is finished in order. This structured approach works well when a client has a limited budget or tight deadlines and we are able to set out clear revisions. This is useful in that it creates a delimited timeframe for completion and should provide the client with a cost limit. The downside is that it is not easy to revise work once a stage has been passed, so if a client changes their mind about some element, it can often mean starting over. The structure is fairly inflexible, which suits some clients better than others.

Flexible, “Agile” approach

The agile approach to project management is more flexible and has become a favourite for IT projects in recent years. An agile method takes a less structured approach and results in different aspects of the build being focused on by different teams. The project is developed through various iterations until a final version is adopted. While the approach is more flexible, there is less certainty about the costs involved as each stage may require several iterations. It also requires the client to be far more engaged in the process.

The five stages

Regardless of whether an agile or waterfall project management methodology is used, the basic principles of managing a web development project fall into five key project management stages. These are the stages used by Redcentaur.

  • Inception: This is about gathering all of the information that will enable you to understand and define the brief, scope and specification with the client. This is probably one of the most important stages to get absolutely right as misunderstanding or misinterpretation at this stage will cause the rest of the project to go awry. This stage should also be used to start building some concepts and principles, drafts and sketches of ideas. Start building a plan of how the project should be carried forward. Make sure that you understand how your client wants to use the site and how their customers/visitors are going to be using the site; are these two requirements compatible?
  • Gateway: meeting with clients to go through main ideas and agree principles and design ideas to take forward.
  • Design: Building on the brief and scope that has already been defined, this stage is where you evolve your ideas and present them to the client. You might have several variations to begin with and with the client decide on a favoured option. During the design stage, you should also have a clear idea for information management, data storage and content management. Make sure you consider the site”s users – who are they and what will they expect to be able to do on the site; make sure you make it simple and easy to navigate, purchase or convert clicks to cash throughout the design.
  • Gateway: agreeing with client the final mock-ups, design elements and data management systems/design.
  • Construction: This is where you start getting your hands dirty with some coding and implement the agreed site design. Site construction is the phase that requires the most concentration. By the end of this stage, you should have an almost-ready-to-go web site for approval by the client that is based on the designs they have agreed. You will need to build any back-end functionality, content management systems, databases, etc. and integrate them into the site. Everything should be tested, tested again and tested to make sure the testing was correct! The more you test at this stage, the easier it will be to reach completion and handover without a headache. By the way, testing might be a good idea!
  • Gateway: internal testing of integrated design on test servers to ensure the design works as intended.
  • Completion: This is where you do some user testing of site on testing server to ensure that user feedback is completed. Reassess and tweek the design, data management, etc. where there are concerns. Assuming you have completed user assessments throughout, you should at this stage make sure that users see the site and use it as expected: ask people to go through certain tasks on the site to make sure that they understand how to do what you want them to do without difficulty or obstacles.
  • Gateway: test with the clients to ensure they are happy with the finished design, ensuring any minor tweeks are resolved and approval is given.
  • Close out: Uploading the completed site to the production servers, final on-line testing on the production server, hand-over to the client and completion of any search engine submissions, etc.

Each of these stages will be described in more detail in future posts that will form a series on project management. The second part is already available, How to write a successful brief.


I am sure that other designers use other methodologies and stages to manage their projects. I would be interested in hearing about them. Leave a comment below, with your views on how you manage projects, or how useful you have found this post.

How to use custom fonts with cufon

Using font replacement on the web

Using font replacement on the web

Are you bored of using the same old ‘web-safe’ fonts on your sites? Developers have been looking for ways to solve the old problem of having just a few fonts available across platforms for some time. The most recent methods of font replacement, such as SWIFr, used flash technology to transform text into a replacement font and to display it on screen as an image. Now, there are a variety of such font replacement methods available, including Cufón to display text in any font you choose; it’s fast, reliable and simple to use.

Cufón uses JavaScript to draw text as you go with the HTML 5 <canvas> element. Despite being an HTML 5 element, support for the tag is widespread and is even available in Internet Explorer 6.

There are two key things to be aware of:

  • Text drawn using Cufón cannot be selected in the browser – it is a vector image transformed by JSON;
  • You must have a license to publish the font on the web and embed it in your site.


Simo Kinnunen from Finland developed Cufón as a web font replacement solution. What Cufón does is transform the font into a scalable vector graphic, convert it into Vector Markup Language (VML), convert the VML into JavaScript Object Notation (JSON) and then embed the JSON into the web page using JavaScript functions and an HTML tag.

The downside is that the text is rendered as a drawing. It may sound complicated but really, it is fairly easy to implement and it is fast and efficient.

Pros and cons

There are pros and cons with all the various methods of font replacement available. Let’s take a brief look at the main ones:


This renders the text as a flash image. There is usually a slight lag between the rendering of the page and the implementation of the font replacement. This can cause a flicker of the original text before it is transformed within SWIFr. The use of SWIFr does not allow the formatting of the text within the page and it relies on technologies that are not core to the browser.


This renders the text as a vector image, using JSON. Like SWIFr, there can be a lag between rendering the page and the implementation of the font replacement that can cause flickering between the original and the rendered font. Again, Cufón uses technology (in this case, JavaScript) to render the effect, which may be turned off by the user in the browser. Cufón is more controllable within the page than SWIFr and is slightly more reliable. It does not require the installation of several different font formats, but it does require a licence to be held for any fonts that are used and published on a web site.


@font-face has been around for a while but it is really starting to come into its own with the advent of HTML 5 and updated browsers that can handle it properly. @font-face is a CSS property, which means that it is fully integrated with the browser and does not rely on any technology to be turned on. It is therefore much faster to render within the browser than the other two solutions. However, it does require various formats of the font to be available, either on the web site or from a font repository, and these have to be downloaded with the page for the font to be utilised on the page. This is a method that is really starting to make headway and is likely to take over from the other font replacement methods that are available in the future. We’ll be looking at this method further in future posts.

Useable fonts

Almost any font can be used with Cufón, whether you have TrueType Fonts (TTF), OpenType Fonts(OTF), Pointer Font Binaries (PFB) or PostScript Fonts (PSF), they can all be used. The only restriction is the licence you hold for that font. Commercial fonts often require you to have a second, more expensive licence to allow you to embed the font into a web site. You must check your licence to ensure that you abide by the licence agreement and not infringe the rights of the font developer.

How do you use Cufón?

    1. Go to cufon.shoqolate.com and download the cufon-yui.js file to your site folder. This is the JavaScript rendering engine that will create the redrawn font.
    2. Set up your web site using normal HTML and CSS and find a font that you can use in accordance with your licence.
    3. Next, go to cufon.shoqolate.com/generate,
    4. Select the relevant font(s) (NOTE: it is advisable to make a copy of the font in a separate folder before undertaking this process to avoid any mishaps to your existing font files),
    5. Choose a name for the font family,
    6. Click to agree that the EULA (end-user licence agreement) allows you to embed the font in your web site
    7. Select all the character sets (glyphs) that you want to use (the fewer selected the smaller the file size)
    8. rovide the domain names for the domains where the font will be used (this stops linking from elsewhere and other security issues),
    9. Select the EM size, optimisation paths and kerning tables for your font — this is a trade off between features and file size, so you need to choose what you are willing to sacrifice for file size here. Bear in mind that for small font sizes it is recommended to turn off path optimisation.
    10. Click on the ‘Let’s Do This’ button and download the file to your web site directory (put it with the cufon-yui.js file).
    11. Now you need to move to your web pages and open them in a text editor. In the HTML page, you need to place Cufón after any calls to stylesheets. You need to call teh rendering engine first, followed by the font file. The scripts are as follows:
      <script type="text/javascript" src="[directory]/cufon-yui.js"></script>
      <script type="text/javascript" src="[directory]/[font-family].font.js"></script>

Now, let’s replace some text elements in the HTML page:

  1. Add the following code below the two script codes you just inserted:
 <script type="text/javascript">

Add some effects

You have now changed the H1, H2 and H3 tags to your chosen font. But the script also allows you to render other effects on your text, such as a

Drop shadow:

Cufon.replace('h1', {textShadow: '1px 1px rgba( 0, 0, 0, 0.2)'});


Cufon.replace('h2', {color: '-linear-gradient(white,#990000)'});
Cufon.replace('h3', {color: '-linear-gradient(#fff, 0.4=#999, 0.5=#ccc, #ccc)'});
// shades into different colours at the specified points - 40%, 50%, to the end of the H3.

Final words

There is no reason why you can’t use this method on any text element in your HTML page. You can also extend Cufón by using a selector engine, such as Google’s.

As with SWIFr and other replacement engines, there is a delay between the page loading and the rendering taking place. To prevent this, simply call cufon.now() before any scripts running prior to the closing </body> tag.

Find out more at: wiki.github.com/sorccu/cufon.

Is IE6 dead?

.net campaign to bring down IE 6

.net campaign to "Bring Down IE 6"

There has been much debate in recent weeks about the death knells of Internet Explorer 6; particularly since .net magazine ran an article in its February 2009 issue (http://www.netmag.co.uk/zine/discover-culture/calling-time-on-ie6 ), which has been supported by some designers.

IE6 is well known for its quirky interpretation of web standards and for requiring significant code hacks to enable web sites to appear as they should. I remember in the Dark Ages of the internet, when Microsoft and Netscape were battling for browser supremacy, that designers started putting “This web site is best viewed in Internet Explorer [or Netscape Navigator]” messages on their sites. At the time there were only a fraction of the people online compared to today, and the internet was not a commercial entity in the way it is today. The decision by Microsoft to gallop headlong into the distance when everyone else was going in another direction has led many designers to pull out what little hair they had left and throw their arms up in despair for many years. I, like most web designers, keenly await the day we can finally bury IE6 for good. However, frustrating and annoying as IE6 is for designers, a word of caution needs to be sounded before ditching the browser from design considerations.

It is important for designers to remember that they do not make browsers; they make web sites for visitors to view in the browser of their choice: a browser is a user-defined tool over which the designer has no control. In the same way, a designer has no control over whether or not JavaScript is enabled on the computer a visitor is using. To say, therefore, that you are not considering IE6 in the design of your client’s site is effectively saying that you are willing to turn a proportion of your client’s customers away.

It is indeed fortunate that more recent browsers have been more closely aligned to web standards and the trend appears to be towards meeting the standards rather than creating their own. Even Microsoft appears to have seen the light with IE7 and 8. So, the question is whether or not IE6 is obsolete now that there are alternatives and updates to preferred browsers available.

On the face of it, this is a compelling argument as IE6 users have diminished in number, seemingly moving to IE7, IE8, or one of the other browsers, such as Firefox, Opera, etc. However, there is a core of users who still rigidly seem to be sticking with IE6 and it might be worth considering who these people are.

Traditionally, they are thought to be dullards who can’t or won’t update their browsers and who need to be forced to do so. Looking at the statistics available from W3Schools, there is a sharp move away from IE6 over the last twelve months: in April 2008, over 29% of visitors used the browser; in April 2009 this figure was 15%. This downward trend can be rationalised by the increases in Firefox, Safari, Opera, Chrome and IE8.

Table of browser usage for 2008 - 2009 from W3C Schools

Browser usage 2008/2009 by W3C Schools

Market Share shows a similar tale. In June 2008, IE6 controlled approximately 26% of the traffic. By April 2009, the proportion dropped to 18%. Again, this trend can be attributed to the massive growth in popularity of Firefox, the growth of Safari and the release of IE8.

Browser trends graph and table by Market Share

Browser trends by Market Share

While these figures are often disputed because they rely on site traffic to the sites that publish the results, what cannot be denied is the continuing popularity of the old browser, IE6 still commands about 15 – 20% of the market share.

But why might this be the case? Are up to 20% of internet users dullards? Of course not. Many of the continuing users of IE6 are large corporate enterprises who deliberately wait before upgrading, to make sure that the latest versions of operating systems and software applications (especially Microsoft) work and are reliable before upgrading themselves. Ending consideration of IE6 at this stage could alienate a large proportion of sizeable corporate clients.

Designers should be led by what the users of their clients’ web sites need. If the client has a large number of corporate customers, chances are that some of them will still be using IE6. Similar chances exist for a large proportion of general users, who are not necessarily technologically clued-up, or might not know how to upgrade (or change) their browser.

It is not the designer’s responsibility to dictate who can view their clients’ web sites. That is a decision that rightly can only be made by the client. However, the designer’s responsibility is to help their clients to reach an informed decision by explaining the problems of IE6, identifying the relevant user statistics for the site (or general stats for new sites), identifying trends over time and demonstrating the pitfalls of not including IE6 as a supported browser.

Taking the statistics from my own site, IE6 accounts for just over 20% of visits in the last year to April. Amazingly, there were even some users still clinging on to IE5.5! However, over the last six months, the trend has completely changed. No-one now is using IE5.5 and IE6 has fallen to 9% of visitors. Firefox has actually overtaken IE as the browser of choice with over 45% market share, compared to IE’s market share of 37%.

Redcentaur's own user analysis

Share of visitors to Redcentaur using IE 6

What this shows me is that if I suddenly switched off support for IE6 now, I would alienate 9% of my visitors. This is something I am not prepared to do as that is equivalent to saying that 9% of my customers are not valued.

The key is for the designer not to unnecessarily alienate a proportion of potential customers for their clients. If it is clear from research specific to the site being designed, that a proportion of visitors are using earlier versions of browsers, then as a designer it is your responsibility to include them in the design of the site.

Clearly, this will require a discussion with your client, where the pros and cons of including IE6 and other browsers are identified. This will also involve a discussion about the additional cost of hacking the site for IE6, which should be costs included in the estimate you provide your client. It is your clients’ decision whether or not to include IE6 within the design – afterall, it is their site, they are their customers and it is their risk.

Personally, I would prefer not to start seeing sites saying “This site is best viewed in Firefox 3.2”. It is really not a professional image to portray for your design or for your clients’ corporate web site.