What is the difference between Interative/Waterfall and Agile Approaches?
What are the phases of the Implementation Process?
What are the steps of the Discovery Phase and how are they important to your project's success?
How do you successfully implement against your specifications and migrate content?
How do you effectively test the deliverables?
This chapter begins by asking a fundamental question: Why do so many website projects fail? Projects fail for any number of reasons, but most commonly, they fail because they didn't follow a standardized methodology. A Web development methodology is the system used to control the process of developing a website. Following a process ensures that the result of your project aligns to the needs of the business, that it addresses all of the components of the site's user experience and that it is a technically solid solution, able to scale and perform in a way that supports your organization's objectives.
This chapter is intended for use by project managers and technical developers who are charged with the responsibility of ensuring that their website development project is a success. It is not intended to be a comprehensive guide to project management. It introduces the Ektron methodology and provides advice and recommendations that help ensure you involve the right people in your website-development project, that they have an understanding of what exactly has to be built, and that you have a solid plan for attaining your goals.
Over the years, a number of development methodologies have been created, including waterfall, iterative, and agile. Waterfall-based methodologies start with the assumption that requirements must be well defined and documented before proceeding into the actual development effort. With a waterfall approach, the project begins with a comprehensive discovery effort, consisting of stakeholder interviews, functional requirements gathering, technical solution development, and the creation of user experience components. In some cases, deliverables may go through a series of iterations before being considered complete. At the end of the discovery process, the business, technical, and creative components of the project are documented, agreed-upon by the appropriate stakeholders, and used as a baseline to measure the progress of the project.
Agile methodologies typically approach the project from the perspective of defining requirements while the development effort is ongoing. Instead of defining all aspects of the project requirements up front, agile approaches prefer to divide the project into a series of segments or sprints. As each sprint is completed, the development effort is presented to the customer and requirements are refined based on direct feedback from the appropriate stakeholders. Clearly, the first several sprints are intended to focus on the core functionality of the website. As feedback is incorporated into subsequent sprints, the website increasingly nears a final format until all sprints are completed and the project is ready to be deployed to the public at large.
There are pros and cons of both approaches. This chapter focuses exclusively on the waterfall approach to website development, as it reflects Ektron's direct experience.
Many people think that website projects begin at the kickoff meeting. However, the truth is that most website projects start well before the actual kickoff. As an example, a business owner makes the decision about starting a new website design project. Depending on the size of the organization, the business owner may be in charge of a line of business or of the entire enterprise. Once the need has been identified, the business owner builds a business case that justifies and articulates the business value of the website property. Typically, this business case is then presented to other members of the management team who can provide funding and approval to move forward with the project.
So, what does a business case consist of? Most business cases document the problems to be solved by a website property. For example, it may be to sell more widgets online. Others may find value in developing a community that can be marketed to. Still other businesses can drive results by reducing service calls to their call centers and moving service questions and issues online. Defining the business side of the website property is at the heart of the business case. Just as no two companies are alike, business cases are extremely personalized to the unique circumstances of the particular business or market.
It can't be stressed enough how important it is for the business case to align to the larger enterprise strategy that drives the overall business. This enterprise strategy may be as generic as "being perceived as the industry expert" or "improving our customer service" or even "leading our marketplace." In these examples, developing a website that allows members of an industry to interact in an industry-specific community or offering customers a personalized customer service experience can be drawn directly back to the larger enterprise strategy. Even generic statements such as "leading our marketplace" can translate into website properties that sell products while measuring commerce transactions through the use of Web analytics.
Once the business case is aligned to the enterprise strategy, it should document the specific functionality that is expected to be part of the final product. The business case should express and articulate the positive business effects of the website property with specificity. The business case should articulate the key performance indicators, or KPIs, that will be measured to document the business success of the investment in the website. Examples of KPIs may include but are not limited to the number of orders, number of unique visitors, session length, up-sell or cross-sell completion metrics, revenue generated, and effectiveness of pay-per-click campaigns. The business's needs and expectations are clearly defined and shared with all members of the team before initiating the project by defining these KPIs upfront as part of the business case.
The business case should also describe the kind of resources required to implement the project, the technical and security performance metrics to be tracked, the implementation timelines, dependencies, business process impact analysis, and the financial investment required to support the new website property. Once well defined, the business case is presented for approval within the organization. With approval, the business case becomes an input to the discovery process and provides valuable definition as to the governing characteristics of both the site as well as the implementation project itself.
As mentioned, the Ektron Professional Services website development methodology follows a process in which each phase of the project methodology builds upon the previous phase. For example, the discovery phase provides the functional requirements that serve as input to the implementation phase. When completed, the implementation phase leads to the system acceptance testing phase, which in turn, leads to the user acceptance testing phase. Each phase serves as 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. The phases are listed below.
If you were to compare the building of the website to the building of a house — say a cliff-top mansion — the discovery phase is the series of activities that involve you meeting with an architect, interior designer, and landscape planner to prototype your ultimate dream home. The implementation phase, by contrast, is where you clear the land, lay the foundation, and actually build the home. The quality assurance phase then, would be getting the home inspected.
The discovery phase of the website development methodology 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. Of course, we know we don't always live in an ideal world. To that end, the discovery process is flexible enough to help define business requirements, if necessary. Recall, this phase would be like drawing up all your blueprints if you were building a dream house.
To begin the actual project, Ektron recommends conducting a formal kickoff meeting. Prior to the kickoff meeting, you should develop an agenda that describes who should be involved in the meeting, what topics will be discussed, and what anticipated next steps look like. Traditionally speaking, the kickoff meeting is focused on introducing team members to one another from across the business, defining specific roles and responsibilities for the team, and reviewing the formal scope of work that covers the entire project. In most project kickoff meetings, one single point of contact — a project manager — is appointed. The role of the project manager is to ensure the scope of work is managed, budget and timeline requirements are met, and risk items are identified and mitigated throughout the implementation process.
In addition to the project manager, many organizations designate a business stakeholder who can speak to the concerns of the business, a marketing or creative stakeholder who can speak to the user experience components of the project, and a technical stakeholder who can speak to the performance and security components of the new website. In many cases, these stakeholders may represent larger teams of subject matter experts who exist throughout the business itself. These key stakeholders will bring other subject matter experts from the business into the project at appropriate times to provide feedback, insight, and other value.
Once individual responsibilities for the team are well defined, the project manager should develop a final, baseline project plan that illustrates and documents the work activity tasks, dependencies, resources, and timelines for the individual project elements. The project plan should take into consideration the time required for signoff and approval of project deliverables, as well as the schedules of people who must provide input throughout the project.
For most projects, detailed business, user experience and technical requirements are not well defined at this stage of the project. To ensure that you have a comprehensive view of the requirements at the outset of the project, each component of the website should be further defined through a series of requirement gathering activities. To address the needs of the business and functional requirements of the website, you should conduct a series of business stakeholder interviews with a variety of stakeholders across the organization. It is especially important to interview all stakeholders who represent the various functions or departments within the organization that the website will affect. Leaving out an important business segment can lead to real problems, so be expansive in your targeting of stakeholders to participate in the sessions.
To make sure the stakeholders are well prepared in advance of the interviews, Ektron recommends that you develop the interview questions and share these questions with the interviewees before actually conducting the interview. Using this method, business stakeholders have the opportunity to research and discuss the questions with other colleagues before answering your questions. The interview format typically lasts between one and two hours and should be conducted in an informal setting.
The interview questions should be focused purely around the business aspects of the website property. You may want to ask about KPI tracking, business goals for the website, and business processes the website will be expected to interact with. Make sure to ask questions that help to define metrics. These metrics can be tracked and measured at the completion of the project to demonstrate the success of the investment. Also be sure to use plain language and avoid any technical jargon or other confusing terms. As you ask the interview questions, make sure you write the answers exactly as the interviewee provides them. It may also be necessary to educate participants about the questions you're asking so they better understand how to respond. These interview questions and responses will be used later to develop a functional requirements document.
Ektron recommends the interview questions be conducted initially in a one-on-one format. Participants are typically more candid and direct in one-on-one scenarios. As you conduct a series of interviews, you will sometimes hear conflicting responses from various participants. In these cases, identify responses that are common across the interviews and use those as the basis for the core functional requirements. You may also hear great ideas or requirements that are outside the scope of the current website project. Make sure to capture these ideas, because they often serve as the basis for future project activities. In this way, you can make sure that each stakeholder feels as though he or she were heard while also maintaining the scope of the project.
In some cases, conflicting requirements can't easily be resolved in a one-on-one format. To address these kinds of situations, it is best to conduct a follow-up consensus-building session. In this scenario, bring together the stakeholders who participated in the interview sessions into a larger meeting. Share with them the elements of the interview responses that were common across stakeholders and diplomatically bring up areas where requirements conflicted. Stakeholders will often work together to resolve conflicting requirements in a group setting.
With the core business requirements having been defined, the next area of focus is the technical aspect of the website. Leveraging the input from the business, identify third-party tools, systems, and applications that might be affected by the new website project.
Next, focus on performance and security standards requirements related to the website. Conduct research and analysis of the current hosting infrastructure to determine whether new hardware is appropriate or if existing IT infrastructure can be leveraged.
Security is another important component of any technical implementation. With respect to user authentication, identify appropriate active directory or LDAP-based authentication repositories. Leveraging the previously captured input from the business, develop flow maps that explain how users can log in, be assigned permission levels, and manage changing contact information. It may be necessary to review any internal IT policies that have been documented relating to security standards.
Finally, consider the implications of your technical infrastructure with respect to Ektron's licensing policies. For example, Ektron offers special pricing designed for implementation into disaster recovery environments. Ektron also offers a wide variety of licensing options that enable multiple data centers, load balanced server farms, and provide other approaches to the hosting infrastructure that powers your website. Remember to consider the development, staging, and production environments as they relate to licensing and hardware-procurement needs.
The next area to focus on during the discovery process is to define the user experience. Typically, this is accomplished in a series of creative deliverables, which includes site maps, Wireframes, and user interface prototypes. To begin, check with your marketing department to determine whether your organization has documented Web or style standards. In the event that the standards exist, it is important to align creative deliverables within these requirements. Determine whether any Web-specific standards exist. For example, your marketing or design team may have specific browsers that they want to support, a preference for fixed width versus fluid design approaches, a list of specific plug-ins that are approved or guidelines for color palette, appropriate imagery, and the use of company logos. It's best to understand these guidelines upfront.
Although many people think the user experience consists of purely graphic design, the truth is that the field of information architecture (IA) is equally important. Information architecture refers to the logical grouping of information in a way that serves specific audiences by being uniquely relevant to those audiences. IA affects the overall hierarchy and organization of information on the website, drives the navigational model for the site, and provides a consistent labeling scheme that aids in clarity for the users. The steps are as follows:
To leverage the input previously provided by the business stakeholder interviews, you develop a site map that graphically illustrates how information is fundamentally structured on the website. The site map should focus on the top three layers of information on your website. It should provide final naming conventions for each major section of navigation found on the site and should guide the development of the folder structure within Ektron's Workarea.
Create a series of Wireframes. Wireframes are intended to serve two purposes.
Organize and define the priorities of the key elements of each page. For example, how wide should the body area be? What kind of navigation scheme should be employed?
Define interaction design. For process-based web pages, it is important to document where information is captured and how to walk the users through Web-based tasks. Wireframes can be used to prototype these interactions. For example, users must register for membership on your website.
Consider graphic design. Develop and design a series of user interface prototypes that represent the major components of your website. Examples include home page, interior sectional page, search page, and any other major sections of the site considered important to the overall user experience.
Note
Ektron recommends that multiple sets of user interface prototypes be developed at this stage of the project. Each user interface prototype should include the exact same sample pages, but have entirely different design treatments applied to them. In this way, user interface prototypes can be presented to business and marketing stakeholders and their feedback can be focused exclusively on the aesthetic treatment of each design set.
Typically, in a website redesign project, at least three sets of user interface prototypes are presented in the initial round of design comps. When presenting the three designs, make sure to educate the stakeholders that they are not to evaluate the actual content of any of the user interface prototypes. Instead these should focus on the color scheme, use of typography, and general layout. Ask the stakeholders to select one of the three design prototype sets and provide feedback for further evolution of the selected design set.
Now that you've completed the requirements-gathering activities related to the business and evaluated the technical and user experience components of the project, you are ready to produce the final deliverables associated with the discovery phase. The Ektron website development methodology calls for the creation of the following:
The functional requirements document: Using the feedback captured during the business stakeholder interviews and any subsequent prioritization sessions, document the specific functional and business requirements of the website. Be as specific as possible when developing these requirements and avoid the natural tendency to try to architect a specific solution.
The information architecture document: Leveraging the site map, develop an information architecture document that captures and documents the higher structure of information on the site. This document defines the types of information you'll find on the site, as well as the structure of the information and how the content items relate to one another through metadata and taxonomy. Comparing it to non-platform projects, this would be similar to an object-relationship map. The combination of these materials should be documented in the information architecture document and will inform the configuration of the Ektron CMS as you enter the implementation phase.
The CMS implementation guide: Leverage the Wireframes and user interface prototypes to create a CMS implementation guide. For each component defined in the Wireframes and or user interface prototypes, define which Ektron Server Controls should be used to address each component of functionality. The CMS implementation guide is Ektron-specific, in that it defines which server controls, which API calls, and which elements of customization are required to meet the business, user experience, and technical requirements for the project. Typically, a technical developer who is already familiar with the Ektron Server Controls and APIs develops the CMS implementation guide.
Please note that it may be necessary, based on the feedback and input captured throughout the discovery process, to revise the project plan that governs the overall implementation effort. When website requirements are poorly understood, projects are structured so that the discovery phase is addressed as a separate project before the implementation phase. In these cases, it is important to develop a comprehensive project plan that governs the remainder of the implementation and testing.
One final note about the discovery process: remember it is intended as a guide. Feel free to scale the discovery methodology up or down to meet your individual needs. For example, some customers may want to include processes such as usability testing as part of the discovery process. Other customers may not be redesigning a website and should bypass the user interface prototyping phase of the discovery process. What's important to remember is that the methodology is as flexible as your unique environment.
The implementation phase is where you start building to the specifications you have been developing. If you follow the project development methodology accurately, the implementation phase should be as straightforward as possible. Returning to the dream house analogy mentioned earlier, the blueprints for the cliff-top mansion would be finished and you would be ready to clear the ground and start construction.
To begin the implementation phase, focus first on the initial setup and configuration of the three environments: development, staging, and production hosting environments, following these steps:
Beginning with the development environment set up and install the hardware.
Install and configure the operating system and IIS Web server.
In a separate environment, and depending on your unique hosting configuration, install, configure, and set up the SQL Server database. Connect the SQL Server and IIS Web servers so that they can communicate.
Download and install the latest version of the Ektron CMS400.NET software. Following the instructions provided with the Ektron software, install a CMS Min environment. This ensures that you are prepared to begin the development effort.
With the steps being completed, repeat them in the staging and production environments as well.
With the three environments now set up and configured, install the Ektron eSync software and configure it to move file system assets and databases from development to staging and finally, to the production hosting environment.
Note
There are a number of ways in which Ektron can be configured. Although this chapter describes a traditional three-tier hosting environment, each hosting topology is different and unique to each customer's specific environment. Even though Ektron provides extensive documentation as to the different configuration choices available, you may benefit from a brief consultation with an Ektron Best Practices Engineer, who can advise you on the optimal way in which your hosting environment can be configured. Also remember to use the Ektron Dev Center website (
http://dev.ektron.com) to run ideas by other community members who have Ektron experience.You now want to develop actual .ASPX templates. Begin this activity by converting the final user interface prototype designs into a series of XHTML and CSS pages.
Before continuing, make sure to conduct browser compliance testing and ensure that the XHTML templates and the user interface will display and function as intended. Making changes to the design and layout of these templates after they have been converted into .ASPX templates is more involved than making the changes earlier in the process. For the presentation layer, using a CSS-driven design and layout will provide you with greater flexibility while also aligning to industry best practice standards.
With the XHTML templates completed, convert the bare XHTML into .NET master pages. Master pages should contain elements of the design that are shared throughout the website. For example, it is often a best practice to have the Search field presented in the upper-right corner of the design. Accordingly, the master page should contain the Search field so it is consistently displayed to the users throughout the website.
Next, leverage the master pages to develop specific .ASPX templates that contain the individual functionality that is not common to many pages. These pages were documented and defined in your CMS implementation guide. If you develop these templates, remember to develop the corresponding folder structure and content within the Ektron Workarea. As you add server controls to the .ASPX pages, remember you must also style the output of these controls to match the user interface prototypes. This is when the CSS you developed to support the templates comes in handy. Sometimes it is important to transform the output of the server control as well as style it. In these cases, leverage XSLT to transform server control output and CSS to define the presentation elements of that output. Wherever possible, standardize and leverage common approaches to both XSLT and CSS standards.
When you are done with these steps, you essentially have a skeleton, or framework, of the website. The next step is to begin loading content into the CMS. Depending on whether the project relates to a new website property or a redesign of an existing website, your approach to content migration and loading may differ.
New website properties: Content is typically developed in the form of Microsoft Word documents. Taking the content from these documents and loading it into the CMS is a process that entails copying and pasting content into individual content blocks.
Redesign projects: If the site being redesigned is already on Ektron, the migration process is very straightforward. Using direct APIs, you can migrate content blocks directly from the previous installation into your new development environment. A similar approach may work if you are migrating content from a site that uses a structured database. However, in these cases, it may be necessary to transform the data structures to align with the Ektron objects. If you are migrating from a site that doesn't have a backend database, you may have to consider a manual approach to content migration. One often overlooked aspect of any content loading or migration process is the need to transform the content to align with the style standards of the new site.
Large-scale content migration projects: It may be necessary to use an automated tool to assist in the extraction, transformation, and loading of migrating content. This is another area where Ektron Professional Services may be of some assistance to you.
Regardless of the method you employed to load the content, make sure to plan for the need to revisit the content to freshen its relevance, update CSS style standards, and fix broken links.
Also when considering content loading or migration efforts, remember you might want to use the following tools to build content for structured versus non-structured data:
Ektron Smart Form: Press releases often follow a very structured format. They consist of a headline, summary, contact information for the PR representative, and the body of the press release. Using an Ektron Smart Form is an ideal way to handle such content.
Traditional Ektron content block: Other aspects of the website may require a more free-form approach to content. For example, the About Us section of the website typically provides basic information about the company, its employees, and its mission. This is an opportunity to use traditional Ektron content blocks to provide freedom and flexibility for the design and layout of the content. These considerations should have been initially addressed during the discovery phase and those deliverables should be used to guide this effort.
PageBuilder Wireframes: These are different from traditional CMS templates in that they define specific zones where content and widgets are placed. With this basic framework in place, content authors can drag and drop pre-built pieces of functionality or content into the zones defined by the PageBuilder Wireframe. PageBuilder Wireframes are typically built using a column-based metaphor. For example, you may have two-, three-, and four-column PageBuilder Wireframes available to your users. With PageBuilder Wireframes in place, your content authors will create the content as well as define the individual layout of PageBuilder pages.
Now that the implementation phase is coming to a close, the next areas you'll explore are the testing and deployment steps.
The testing phase of the project methodology is intended to capture and resolve any issues, bugs, or problems with the website. Revisiting the analogy about the construction of your dream house, the cliff-top mansion, this phase is where you bring in an inspector to ensure the building is up to code, and that the attic light doesn't turn on when you flip the garbage disposal switch.
Using your own internal resources, you begin the system testing phase by documenting specific test cases created using the business and functional requirements obtained during the Discovery Phase. Use cases are intended to describe specific tasks or activities that users are expected to perform using the website. They typically are task-based and verifiable. This means that through testing you should be able to determine whether the site behaved as expected after testing. If not, the use case needs to be refined and clarified. For example, a verifiable use case would be to "enter in the search term <HR Form> and see five results listed in the search results." A non-verifiable use case would be to "provide search functionality."
If there is one overlooked aspect of website development, it is typically in the testing processes. As you develop your use cases, be expansive and remember to not only cover just the tasks described in the business requirements, but also commonly used website functions, such as search and contact forms. Once your use cases have been fully developed, follow them throughout your testing process. As you identify issues during the use case testing, document the URL, the expected behavior, and the actual results you encounter during the testing.
Note
It is common to conduct multiple rounds of system testing before moving into user acceptance testing. Remember also to test all aspects of the website. For example, if your website has integration with a third-party tool or application, make sure to test that the information captured in the CMS is accurately migrated to the other system or tool.
As you identify specific issues, document them in a testing spreadsheet or defect tracking tool. Use this defect tracking system with your development team to research, analyze, and resolve each individual issue. As you resolve issues, document the response to the reported issue in the same tool. This provides you with a detailed record of both testing issues documented as well as issue resolution. You can use the same format as you enter the next, and final, phase of testing.
The final phase of activity before completing and deploying the new website 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 use actual end users to complete the testing.
Before user acceptance testing can begin, however, it is important to ensure that the actual end users of the CMS powered website have been trained and know how to manage the site and its functionality. Ektron provides detailed system documentation as well as training materials to all of its customers. However, you may find developing custom author or administrator training materials to be helpful as you educate your end users. It has been Ektron's experience that delivering custom training in an instructor-led, hands-on format is the most effective way to empower the author and administrator audiences.
As before, the use cases will drive the testing effort. Ask your end users to follow the use cases and report any identified issues in the same testing spreadsheet format that you used in the earlier phase of testing. Again, you may decide to do multiple rounds of user acceptance testing before you decide that the site is ready for an appointment. As issues are identified by your end users, involve your IT staff in researching and resolving the reported issues.
When the testing process is complete, training delivered, and a final check of system functionality, you are ready to deploy the new Ektron-powered website to the public at large. Using Ektron's eSync technology, you can quickly deploy content and file system assets from your development to staging and, ultimately, your production hosting environments. Once the site is deployed to the production hosting environment, update the DNS entry for the website point to the production servers. Within 24 to 48 hours, the site will be available to the public at large and you will have your most visible demonstration of the success of the project.
However, this is not necessarily the end of the project. Now that the site has been launched, it is time to enter the ongoing maintenance mode that governs the website until the next major enhancement or release. It is critically important that at this stage of the project, you begin the detailed tracking and reporting of the KPI metrics you defined in the discovery phase of activities. If the initial investment in the website was based on demonstrable business impact, these KPI measurements help to prove that the expected result has, in fact, been attained.
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 can allow you to quickly change your mind and react to how your customers perceive and interact with your website property. So many projects count success as the mirror launching of a new website. Real success, however, is measured over time and in your newfound abilities to react to the marketplace.
Before this chapter on the Ektron website development methodology ends, the authors want to share a couple of final thoughts and important points to keep in mind:
Carefully manage the scope of the project. If you do not do this, 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.
For example, during the testing process, it is almost inevitable that business users will come up with new ideas and ask for changes. As this occurs, make sure to document the request and assess the impact of the change in both financial and timeline views. Many times, when presented with a specific dollar number and timeline change, business stakeholders will reevaluate the request and either provide additional funding and time to complete the change or decide that the change is something that can wait until the next phase. Effectively managing change requests can be the difference between a project that launches on time and on budget versus a project that never seems to launch and misses the budget wildly.
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 revisit the functional requirements for the website often, paying special attention to those items that were deemed appropriate for future expansion and Ektron features that you may not have used during your initial development effort.
Making simple changes to the website that adds functionality will extend the life and business value of the website investment. A great example of this is an organization that decides to implement Ektron's core website analytics package, and later decides to extend the feedback loop through the use of multivariate testing in a PageBuilder interface. For an established site, this is an easy expansion that can significantly help with KPIs. These types of small enhancements increase the effectiveness 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.