ÃÛ¶¹ÊÓƵ

An interactive checklist that lets you track and monitor your progress with these best practices.

• Defines inputs and deliverables according to phase, milestone, and persona.
• Provides automated overviews (quality, health, and completeness) to indicate progress and project-health.

Documentation based on the checklist that details the:

• Project Heartbeat analysis.
• Status by Role overview.
• Phases and Milestones.
• Key Persona and their involvement at every (relevant) stage.
• A Glossary of the Required Documents and Deliverables.

Further reference material to provide more details on specific areas.

Phase Quality

• Indicates the quality of the Required Documents and Deliverables across the project.

Phase Health

• A high-level status indicator for your project; useful to highlight areas that may be at risk.

Phase Completeness

• At any point in time during the project this indicates how much has already been completed for each phase of your project.

Business Rationale

• The fundamental reasons and justification for undertaking the project.

Scope and Schedule

• A basic scope, and rough schedule should be made available to define what is required, and within which time frame; if it helps clarify the situation, you can also define what lies outside the scope.

Validation

In this phase, you must validate and confirm the goals for the project; for example:

• What do you want to achieve/provide?

• Who benefits?

• What is the scope?

  • If it helps clarify the situation, you can also define what lies outside the scope.

• How do you define success?

• How do you measure success?

• What are the requirements, business and technical?

• Are there legacy systems to be replaced and if so, is there data to be migrated?

• Who is involved?

• How do you measure progress?

• How often do you review progress during the life of the project?

Budget

Before you start any project you need a reliable, realistic estimation of what it costs to implement:

• Use information from the validation milestone as a basis for the estimates.
• Be realistic in your estimates.
• Consider and respect any client guidelines, processes, or restrictions that the client is subject to.
• Consider contingency and review processes if a review or refinement of the budget is required later on.
• Remember that costs come in many forms such as purchases, use of resources, and fees, among others.

Handover

A clean handover ensures that the appropriate persona/groups are aware of their responsibilities within the project.

Full details should be provided/generated to ensure they have a full understanding of all relevant aspects, including the roadmap, scope, goals, requirements, and KPIs.

Risk Assessment

To avoid unpleasant surprises, use risk assessment to identify and quantify any potential risks together with their impact and probability.

This should be done early in the project life cycle to ensure that any vulnerabilities are identified and evaluated. Based on the findings you can report to your stakeholders on whether the full requirements can be implemented and, if necessary, whether it is possible to plan for appropriate actions to be taken and tracked.

Communication

Communication is always key to the success of any project. Communicate clearly and efficiently to ensure that everyone is:

• Working towards the same basic goals
• From the same information base
• With the same channels

Kick Off

The Kick Off meeting is used to raise awareness that the project is starting. It is a good opportunity to:

• Invite all interested parties (or at least group-representatives).

• Present key facts about the project.

• Answer questions.

• Ensure that everyone has the same knowledge base.

• Get commitment from everyone who will be involved - this will have to be earned.

  • By involving prime players (including prospective authors) at the very start of the project, you increase your chances of getting their commitment to the project.

Development Team Staffed and Trained

Before starting on any project, you should ensure that your development team is appropriately staffed and that all team members are trained for the task in hand.

Content Architecture

The content architecture defines and describes the future architecture of the content; including:

• The content tree; including assets
• Basic structures; including campaigns, and so on.
• Multisite and multi-language structures (MSM, Translation, and so on)
• Supportive content (including tags and tagging concepts)
• Caching and content reuse strategies

System Architecture

The system architecture defines the conceptual view of your system; including (among other information):

• System structure for all required environments

• Subsystems

• Third-party systems

• Interfaces; hardware, software, and human interaction

• Servers for each environment; see the Technical Requirements and Hardware Sizing Guidelines

• Processes for each environment; for example, deployment and maintenance requirements

• Maintenance activities (Datastore GC, TarPM optimization, and so on)

• Dispatcher caching

• Clustering Publish/Authorshare

• Performance for the client-side (JS minify, concat, css sprites, total number of http requests, and others)

Application Architecture

The application architecture defines and describes the behavior of the proposed applications.

It is focused on:

• How they interact with each other and with users.
• The data to be consumed and produced by applications, rather than their internal structure.

The definitions should cover:

• Basic code structure for the project
• Code artifacts (bundles, packages, and so on)
• Breakdowns of the templates/components and their relationships
• High-level details of required customizations (specific overlays follow later)
• Design of workflows required by the solution (for example, content creation, approval, publishing, transformations, imports, and exports)
• Special consideration for any complex modules, such as MSM, Commerce, third-party integration

System Integration

System integration requires you to plan (then implement):

• How all the subsystems and solution integrations are brought together to operate as one coherent system
• How any third-party systems are integrated; together with any special considerations, such as offline/online, client-side/browser-side, or fallover handling when a third-party system is down

Test Concept

Before starting development, you should draw up an in-depth and comprehensive concept of all testing requirements for your project.

This should include (among others):

• Details of all tests to be performed
• Preparation of any content required for those tests
• Information of any test tools to be used
• High-level indication of who will be involved in testing; especially groups outside the QA team
• Details of test automation; for example, with Selenium or AEM Developer mode

Experience Design

Experience Design (XD) involves designing the user experience for your solution.

The user experience should be analyzed and developed for both your authors and the final users of your website.

Support Setup

Before development, all support processes required to deploy, release, test, and report issues, should be set in place.

See also the ÃÛ¶¹ÊÓƵ Support Portal.

Permissions

You need to plan and then implement a Roles and Rights Concept for all users/groups that will use the solution.

For example:

• A list of roles (that is, groups) with read/ write access definitions for each

• Definition of the use of privileges that impact the publish environment; for example, replicate

• For users with minimal privileges, workflows should be defined

• Users in the editor group should not have admin rights nor be part of the administrators group

For more information, see User Administration and Security.

Monitoring and Maintenance

Monitoring and maintenance are key aspects of ensuring the smooth operation of your solution once it goes live. For this you need to define:

• What needs monitoring
• Maintenance tasks; both regular and for special cases

See also Monitoring and Maintenance for more information.

Migration

Any content from the legacy system should be reviewed and validated for migration.

Recovery Plan

Ensure that you have a recovery plan in place. In an emergency situation, this must be available to secure the production use of AEM… This should cover situations such as backup, restore, fallover, and others.

Development Environment

Plan and document your development environment, including:

• Architecture

• Development tools

  • A typical environment consists of:

    • an issue tracking system; such as Jira
    • an IDE; such as Eclipse
    • a build management tool; such as Maven
    • a tool for continuous integration; such as Jenkins
    • a tool for version control; such as GIT/SVN
    • a build artifact repository manager; such as Archiva/Nexus

• Third-party software integration/dependencies

• Solution integration/dependencies

• Deployment cadence

Test System

Plan and document your test environment, including:

• Architecture
• Dependencies on development builds; including nightly builds
• The possibilities for, or limitations of, testing third-party software integration/dependencies
• Testing tools
• Automated testing strategy

Production System

Plan and document your production environment, including:

• Architecture
• Deployment cadence
• Third-party software integration/dependencies
• Security setup
• Baseline performance verified by running the Tough Day tests on the production setup
• Requirements for performance tests; see Best Practices for Quality Assurance

Integration

Plan, document, and test all aspects of the system and solution integration, including:

• An automated testing strategy
• Automated processes to move applications from development to test, then production
• Automated processes to move content from production to test and development

Migration

Plan, document, and test all aspects of the content migration; including:

• Content architecture
• Migration strategy

Communication

Ensure that all team members and project persona are kept up-to-date, as necessary.

Documentation

Document the solution fully; including:

• Operations Manual
• Any customizations that may affect upgrades
• Release notes

End-User Acceptance Test

User acceptance testing (UAT) is crucial to ensure that:

• The solution fulfills the user/customer requirements
• The customer/users accept the solution (function, design, and performance)

There should be a formalized checklist for customer handover; ideally automated and run on a nightly basis against a snapshot. The results should be sent to the project manager and development team

Performance and Load Tests

Performance and load tests are used to ensure that the solution meets the required performance levels, at average and peak loads.

For more information about performance testing, see:

• Performance Testing

• How to plan and run testing

• Basic Performance Guidelines

Preparation

Preparation and planning will help ensure a smooth rollout.

Training

Ensure that all involved staff have been trained.

See in the course catalog.

Administrators Trained

Ensure that your solution administrators have:

• Been trained
• Received the appropriate training material
• Received the appropriate documentation

Users Trained

Ensure that your authors have:

• Been trained
• Received the appropriate training material
• Received the appropriate documentation; for example, the User Guide

Penetration Tests

Penetration tests simulate an attack on a computer system to identify potential security weaknesses.

Penetration/Security Tests

To ensure the security of your solution, perform specific penetration tests, together with a wider range of security tests.

See the Security Checklist for more details.

Preparation

Preparation and planning will help ensure a smooth Go Live.

Security

Confirm the security of your solution for both internal and external users and their content.

Fallback

Ensure that all systems, procedures, and mechanisms required for fallback are in place before going live.

Support

Ensure that support services are in-place and ready.

Transition

Plan and execute the transition to your production environment and users.

Roll Out

Prepare and execute your smoke tests.

Responsible for providing/presenting the business case for the project.

Key to shaping and defining the scope of the project; including:

• the definition of, and criteria for, success
• the main KPIs

Provide the main milestones based on the client roadmap.

Is primarily responsible for gathering and analyzing the high-level requirements, then transforming these into specifications:

• for the project manager to use when planning the development
• for the development team to work from during design and development.

Works closely with the client to analyze the requirements. They match these against:

• The definition of success.
• The criteria for success.
• KPIs (both business and performance based).

Is responsible for the technical delivery of the project.

Is responsible for selecting a development methodology that is compliant with client requirements.

Draws up the development strategy:

• ensuring that it is aligned with the business and performance KPIs
• taking into account the success criteria and definition

Works closely with the architect (especially when drawing up the development strategy for AEM) to define aspects such as the relationship between templates and components, the integration strategy for third-party applications and any specialized functionality.

Is responsible for overseeing the project infrastructure.

Is responsible for:

• the setup of internal development and test environments
• for matching those systems to the client systems

Provides hardware recommendations, monitor the various implementations and provide operations support both prior to go live and afterwards.

Stakeholders

• People (often from the business) who have an interest (stake) in the success of the project. They often contribute to the budget.

Legal

• Legal advice is required when negotiating contracts.

Trainers

• Depending on the scale and nature of the project, specialized trainers can be used to develop and present training sessions for the relevant groups.

Technical Writers

• Depending on the scale and nature of the project, specialized technical writers can be used to write guidelines and manuals for specific groups. For example, a Maintenance manual for system administrators or a User Guide for the authors.

System Administrators

• Responsible for the ongoing operation of the system.

Authors and End Users

• The people who use the system to create and maintain your website content.

Other Best Practices and Guidelines related to Managing an AEM project:

• Hardware Sizing Guidelines
• Enterprise DevOps
• SEO and URL Management Best Practices
• AEM and the Web Accessibility Guidelines
• General Data Protection Regulation* Deploying and Maintaining best practices

Administering best practices

Developing best practices

Authoring best practices

AEM Documentation
In addition, the following sections of AEM documentation are of particular interest (however, this list is not exhaustive):

• Security

• Recommended Deployments

• Enterprise DevOps

• Hardware sizing

• Concepts of AEM:

  • Developing - the basics
  • MSM concepts
  • HTML Template Language (HTL)

Related Documentation

• ÃÛ¶¹ÊÓƵ Experience Cloud - Planning for the ÃÛ¶¹ÊÓƵ Experience Cloud