ie8 fix
madison

Better website development and deployment - a practical methodology

Bill Rodgers, Ektron, Special to ZDNet | April 21, 2011 12:01 PM PDT

Summary

In order to be truly effective, there are 4 phases that development must go through, whether for a new website or the rebrand of an existing site, says Ektron's Bill Rodgers.

Commentary - Website projects can fail for a number of reasons, but most commonly, because they didn't follow a standard methodology. A web development methodology is used to control the process of developing a website, where each phase builds upon the previous phase and each phase serves as an input to the following set of activities. Omitting individual phases or not addressing all aspects of an individual phase can seriously put the project’s success at risk. In order to be truly effective, there are 4 phases that development must go through, whether for a new website or the rebrand of an existing site.

Phase One: The Discovery Phase
The Discovery Phase is designed to capture the detail level view of requirements from the perspective of business, creative and technical stakeholders. Fundamentally, the Discovery Phase is focused on answering the question: “What do you want your website to do?” In an ideal situation, a business case has been developed and approved that can provide a guide to the entire Discovery Phase. Within the Discovery Phase are several steps:

• Kicking Off the Project - It is important to conduct a formal kickoff meeting. The agenda should describe who will be involved, what topics will be discussed and what anticipated next steps look like. In most project kickoff meetings, a project manager is appointed as well as designated business, marketing and technology stakeholders who can speak to the concerns of the business.

• Developing a Project Plan - Once individual responsibilities for the team are defined, the project manager should develop a baseline project plan that documents the work activity tasks, dependencies, resources and timelines for the individual project elements.

• Gathering Business Requirements - For most projects, detailed business and user experience and technical requirements are not well defined. To ensure that you have a comprehensive view of the requirements, each component of the website should be further defined through a series of business stakeholder interviews.

• Gathering Technical Requirements - Once the core business requirements have been defined, it is important to identify third-party tools and applications that can be affected. This effort can include identifying whether the current infrastructure will support the project or whether new hardware is appropriate. As part of this effort, you should also focus on setting security requirements and reviewing licensing policies.

• Gathering User Experience Requirements - To begin, check to determine whether or not your organization has documented web or style standards. In the event that standards exist, it will be important to align creative deliverables within these requirements.

While many people think the user experience consists of purely graphic design, the truth is that the field of information architecture (IA) is equally important. IA affects the overall hierarchy and organization of information on the website, drives the navigational model and provides a consistent labeling scheme that aids in clarity for users.

• Creating the Discovery Phase Deliverables - Now that you've completed requirements gathering, the website development methodology calls for the creation of:

1. The functional requirements document
2. The information architecture document
3. The Content Management System (CMS) implementation guide

Once everything has been appropriately documented, it is time for the Implementation Phase.

Phase Two: The Implementation Phase
This is where we start building to specification. If we were to compare the building of the website to the building of a house, the Discovery Phase is where you meet with an architect, interior designer and landscaper to prototype your dream home. The implementation phase would be where we clear the land, lay the foundation and actually build the home. The steps involved in the Implementation Phase include:

• Starting Development - Focus first on the initial setup and configuration of the three environments: development, staging and production hosting environments. It is important to note there are a number of ways the software environment can be configured. While we mentioned a traditional three-tier hosting environment, each hosting topology is different and unique to each customer's specific environment.

• Content Migration - Once a framework of the website is complete, the next step is to begin loading content into the content management system (CMS). Depending on whether or not the project relates to a new website or a redesign of an existing website, your approach to content migration may differ. For new website properties, content is typically developed in Microsoft Word documents. For redesign projects, there are multiple approaches to consider. For example, using SQL scripts or direct APIs, you can migrate content blocks directly from the previous installation.

Phase Three: The Quality Assurance Phase
Once implementation is complete, it is time to test. The testing phase of the methodology is intended to capture and resolve any issues, bugs or problems. If there is one overlooked aspect of website development, it is typically in the testing process. As you develop use cases, be expansive and remember to not only cover the tasks described in the business requirements, but also commonly used website functions, such as search and contact forms. There are two stages of testing:

• System Acceptance Testing - Using internal resources, begin the system testing phase by documenting specific test cases created using the business and functional requirements obtained during the Discovery Phase.

• User Acceptance Testing - The final phase of activity before deployment is to conduct user acceptance testing. With the previous testing phase, you used IT developers and QA staff to do the testing and issue resolution activities. In this phase, you will use actual end-users to validate the site experience.

Phase Four: Deployment
When the testing process is complete, training delivered and a final check of system functionality, you are ready to deploy.

Remember, once the website is launched, you still have ample opportunities to tweak, modify and enhance the content, layout and functionality of the website. Use this capability to measure your expected results and make changes as appropriate. No other medium has the ability to allow you to quickly change your mind and react to how your customers perceive and interact with your company.

It is also critically important to be detailed in the tracking and reporting of the KPI metrics as defined in the Discovery Phase of activities. If the initial investment in the website is based on demonstrable business impact, these KPIs help to prove that the expected result has been attained.

Always keep in mind, although many projects count success as the mere launching of a new website, real success is measured over time and in the newfound ability to react to the marketplace.

Conclusion
It is critical to remember that the scope of the project must be carefully managed throughout the process or you are almost guaranteed to miss your budgetary and timeline constraints. This is a problem that every website development project faces. However, leveraging an effective change management process can mitigate scope creep by using the discovery deliverables as a baseline to measure against.

Also remember that a website is really never fully completed. Instead, websites live in specific time frames, constantly evolving and changing to meet the expanding expectations and needs of your customer audiences. Remember to often revisit the functional requirements for their website, those items that were deemed appropriate for future expansion.

Making simple changes to the website that adds functionality will extend the life and business value of the website investment. These types of small enhancements increase the ROI of the original business investment in the project and also serve to provide constant “little wins” related to the website that reminds people of the value of both the site as well as the platform it's built upon.

biography
Bill Rogers is CEO and founder of Ektron, Inc.

10
Comments

Join the conversation!

Just In

...
adron 28th Apr 2011
adamanderly: ditto

Read Rework, stop perpetuating bad business practice based on bad business culture. Just because treating people bad appears to "work" doesn't mean you should do it.

#justsayin
0 Votes
+ -
Gathering requirements
rynning 21st Apr 2011
"Gathering" implies that the requirements are simply scattered about, waiting to be found and implemented. The correct word is "determining" which implies that they may be unknown and only documented after a potentially tedious exercise. This is often closer to reality.
An editor should take a look at this, it says published 2011, clearly it should read 1991
Bill, you seem to be describing the waterfall model which outside of large consultancies which like to charge $$$ for writing large documents is no longer considered best practice. Agile methodologies are considered best practice now.
Is this a post from, like, 2000? A phased approach? "Once implementation is complete, it is time to test." Only deploy when you are done testing?

I humbly submit that you might want to intersperse some of those activities into a more iterative approach to reduce the time and cost of getting things wrong and discovering it late in the phases.

I just checked the date of the post again. It is 2011. Someone pinch me.
Agree, this is almost exactly a description of the waterfall model, a cornerstone of government contracts, which are not generally known for their efficiency OR quality.
I wrote a blog post on phase-based approaches recently as well - http://www.adventuretechgroup.com/2011/04/making-change-difficult/

LET WATERFALL REIGN!!! Articles like this give me more ammunition for my presentations outlining differences in tradition versus pragmatism.
This might be ok or somewhat tolerable at a really high level, but at the development level this means a death march. It will effectively KILL your software projects - as other commenters have pointed out, a project must follow the agile ideals (not I did not say processes) in order to have hope of success. The processes people have developed around those ideals add to that success factor, but injecting the waterfall nonsense will destroy morale, drag out the project, overrun the budgets, increase staff turnover, generally piss everyone off after a short time, and do many other unspeakable things. I've seen it first hand. Also, read the following:

http://www.amazon.com/Death-March-2nd-Edward-Yourdon/dp/013143635X

http://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959

You have been forwarned. Do NOT force the waterfall onto a dev team.
Hello everyone. Thank you for your feedback on the article. The reality is, Ektron's Partners and Ektron's own Professional Services department selects a methodology based on the organization with which it's working. Ultimately for a process to succeed, it needs to be selected based on the goals, culture, and experience of the organization. This means in some cases, a client might prefer and select Waterfall, while others choose an Agile process. In the Ektron Wrox Book that I co-authored, we stress the importance of standardizing on a development methodology before starting the project (be it agile, waterfall, iterative, or something else). The ZDNet article unfortunately ran focusing exclusively on Waterfall and fails to mention anything else, as we consider in the Ektron Wrox Book. We have a long history of working with Enterprise organizations that embrace agile methodologies and work with Ektron due in part to our ability to deliver successful projects using Agile processes. We recognize that there isnt one single methodology that works for all organizations, and we carefully select a methodology with our clients to suit their needs. The ZDNet article should have reflected this.
0 Votes
+ -
Read REWORK and "live in the NOW!"
adamanderly 26th Apr 2011
"A good plan violently executed today is far and away better than a perfect plan next week." ~ General George S. Patton
0 Votes
+ -
...
adron 28th Apr 2011
adamanderly: ditto

Read Rework, stop perpetuating bad business practice based on bad business culture. Just because treating people bad appears to "work" doesn't mean you should do it.

#justsayin

Join the conversation!

Formatting +
BB Codes - Note: HTML is not supported in forums
  • [b] Bold [/b]
  • [i] Italic [/i]
  • [u] Underline [/u]
  • [s] Strikethrough [/s]
  • [q] "Quote" [/q]
  • [ol][*] 1. Ordered List [/ol]
  • [ul][*] · Unordered List [/ul]
  • [pre] Preformat [/pre]
  • [quote] "Blockquote" [/quote]
ie8 fix

The best of ZDNet, delivered

ZDNet Newsletters

Get the best of ZDNet delivered straight to your inbox

Facebook Activity

ie8 fix