Project Checklists

You are reading the AEM 6.2 version of Project Checklists.
This documentation is also available for the following versions:  AEM 6.1  AEM 6.0  AEM 5.6.1  AEM 5.6  CQ 5.5  CQ 5.4 

Best practices for project delivery

The following checklists guide you, through all phases of the project lifecycle, to a successful project delivery. They are intended as a set of best practices for project delivery. To deliver high quality services, you need to complete all items in the checklists, preferably in order.

The checklists contain Input elements and Output elements. There is no 1:1 correlation between inputs and outputs; for example, a collection of several inputs can result in one output.

* Adobe AEM Project Checklist 18.xlsx
The AEM Project Checklist is available to download and use to create a working draft.

Preparation

The preparation of your project requires a collection of requirements, a roadmap and other up-front work which should result in:

Validation

Input Output
Customer roadmap
  High level solution design  
Scope document   Architecture draft  
Return On Investment (ROI) expectations   Hardware estimates  
Initial experience designs requirements   Performance KPIs  
Business requirements documentation   Project efforts  
Technical requirements documentation    

Note

Key Performance Indicators (KPIs) are:

  • Number of parallel authors and users (concurrency)
  • Response times
  • Number of assets per day (average and peak)
  • Number of page modifications per day (average and peak)

Budget

Input Output
Scope document   Validated budget plan  
High level solution design    
Hardware estimates    
Project efforts    
Requirements documentation    

Planning

The planning of your project must start with a good understanding of the project by everyone involved. You also need to have a sound knowledge of the risks your project will be exposed to, and a plan on how you will communicate throughout. This will provide a sound basis for the start of your project. Completing these 4 checklists will help you cover the main points:

Handover

Input Output
Customer overall project roadmap   Performance KPIs document  
Project scope definition   Project management understands the scope of the project and the expectations  
ROI expectations    
Initial experience designs    
Business and technical requirements documentation    
High level solution design    
Architecture draft    
Hardware estimates    
Historical performance KPIs and expectations    
Relevant contract terms    

Note

The project management team needs to have a clear understanding of:

  • the throughput for the site
  • the numbers of visitors including peak times (for example events iDay, Superbowl and so on)
  • the page render times millisecond granularity, including third party integrations
  • the asset delivery 
  • the caching strategy

Risk Assessment

Input Output
Identify critical key solutions and functionalities   Technical risk factors are known and understood  
Customer roadmap  project timeline   Adjustment of the scope and features required  
Technical and Business Risk Assessment   Results and business decision proposal  
Proof of concept (POC), design and implementation   Technical risk factors verified  
Test and verify POC against Requirement Documentation    

Note

The identification of solutions that can be a potential risk (for example MSM, Commerce integration, and so on) is important. The result will be the basis for reporting into the business whether the full requirements can be implemented or even whether other concepts need to be adapted. In case the solution concept is fraught with risks, the business requires a decision template on how to deal with those key requirements.

Communication

Input Output
Definition of internal and external Stakeholders   Issue tracking process is set up and integrated  
Issue Tracking System and processes from involved parties   Project status reports within a defined cadence  
Status Report format definition    
Reporting Cadence    

Kick-Off

Input Output
Customer roadmap   Project team understands project and expectations  
Project scope document   Hardware will be available to fulfill requirements  
ROI expectations   Agreement on KPIs, defined as goals for project  
Initial experience designs   Project team is aware of the communication plan  
Requirements documentation    
High level solution design    
Architecture draft    
Hardware estimates    
Performance KPIs    
Timeline and milestones    
Project organization and communication    

Note

For more information about kick-off requirements, see also:

Preparing for Development

Before the actual development, there are several prerequisites to ensure that your team is ready to go for it:

Development Team Certification

Input Output
AEM technical trainings   Staff trained  
AEM certification   Certified AEM Component Developers (75%)  
  AEM Lead Developer Certified (minimum of 1)  
  AEM Architect Certified (minimum of 1)  

Note

For AEM trainings and certifications, see:

Content Architecture

Input Output
Initial experience designs   Content architecture definition  
Requirements documentation   Feasability confirmation on KPIs  
High level solution design    
Architecture draft    
KPIs definition    

Note

This checklist should result in a definition of:

  • Basic structures (content, assets, campaigns, etc.)
  • Multi site and multi language structures (MSM, Translation, etc.)
  • Supportive content (tags, ...)
  • Cached versus uncached content

System Architecture

Input Output
Requirements documentation   System architecture definition  
High level solution design   Run baseline tests on an out-of-the-box installation of AEM, using preferred automation testing suite, confirm deviation to plan and adjust.  
Architecture draft   How KPIs for performance and scalability can be met?  
Hardware estimates    
KPIs definition    
Sign off with lead developer checklist    
Performance and scalability concept    

Note

This checklist should cover:

  • Hardware Sizing Guidelines
  • Required environments (dev, stage, prod, other?)
  • Servers and processes for each environment
  • Maintenance activities (Datastore GC, TarPM Opt, ...)
  • Matching KPI's from Sales Handover
  • Dispatcher caching 
  • Clustering Publish/Authorshare 
  • Most important: Performance for the client-side (JS minify, concat, css sprites, total number of http request, and so on)

Application Architecture

Input Output
Requirements documentation   Run baseline tests on an out-of-the-box installation of AEM, using preferred automation testing suite, confirm deviation to plan and adjust  
High level solution design   List of components and templates to be developed, dialog definition, together with important properties (name and type) for all of these  
Architecture draft   Implementation concept for specific (large) modules of AEM when used  
Hardware estimates    
KPIs document    
Component and template concept    
Special functionality concept    

Note

This checklist should cover:

  • Basic code structure for project
  • Code artifacts (bundles, packages, ...)
  • Templates/components breakdowns and their relations
  • Required customizations (high level, specific overlays later)
  • Design of general workflows that the solution must support (content creation, approval, publishing, transformations, imports, exports, ...)
  • Special attention on complex modules, such as MSM, Commerce, third party integration

System Integration

Input Output
Third party integration requirements   Technical concept for third party integration  
Service level agreements defined and in sync with the platform   Support process and emergency plan  

Note

This checklist should cover:

  • Technical concept on how the third party system will be integrated (offline/online, client-side/browser-side)
  • Fail-over handling when third party system is down 

Test Concept

Input Output
Initial experience designs   Test concept documentation  
Requirements documentation   Test plan  
High level solution design   Customized Tough Day, covering customer use cases  
Transform performance KPIs into Tough Day   Formalized acceptance tests  
Use cases / customer stories   User stories, dissected into click paths, to generate executable test cases  

Note

Tests automated with, for example, Selenium or AEM Developer mode.

Support Setup

Input Output
Setup support processes (Partners/Customers/Adobe)   Staff understands the support processes from Adobe  
List of users require access to Adobe Support Portal   Staff has sufficient permission in Support portals  
Definition of escalation process   Staff understands escalation processes  
Request for setting up project section in Adobe Support Portal   Project setup in Adobe Support Portal  

Note

See the Adobe Support Portal.

Only trained developers are allowed read/write access.

Development

Successful development is crucial to your project. The first step towards this involves completing the following checklists:

Development Environment

Input Output
List of standard development tools to be used in the project   Development environment set up  
High level solution design
  Development system ready  
Architecture draft    

Note

A typical environment consists in an issue tracking system, an IDE (such as Eclipse), Maven, Jenkins (for continuous integration), GIT/SVN, Archiva/Nexus.

Test System

Input Output
High level solution design   Test system ready  
Architecture draft    

Note

The test system must:
  • be ready for development releases and nightly builds
  • preferably have similar sizing as the production system for performance tests

Production System

Input Output
System architecture definition   Production system ready  
Run Tough Day test on final production setup   Baseline performance verfied with Tough Day Test  
Disk performance test   Disk performance (DiskBenchmark) result with a valid pattern  

Note

To help you achieve this checklist, see:

Integration Test

Input Output
Integration test setup   Automated deployment process  
Role Definition for IT and/or Unit Tests    

Note

This checklist should cover:

  • Automated process to move application from dev to test to prod (and content the other direction)
  • Definition on which level developer should test (i.e. IT, Unit)

Documentation

Input Output
Document customizations which affects upgrades, hotfixes   Operations manual (user guide)  
Document operational tasks    
Release notes    

Note

The operations manual must contain:

  • Information about changes that may affect installed systems and content
  • Information about customizations and overlays that may affect upgrades, hotfixes, etc.
  • Information about operations related tasks (configuration, etc.)

Performance and Testing

Good performance is also key to a successful project:

(End-) User Acceptance Test

Input Output
Release running on production   Functionality of the application is accepted by stakeholders  
Acceptance test   Formalized checklist for customer handover; ideally automated and run on a nightly basis on snapshot, yielding results, sent to project manager and development team  

Note

Final check for functional/workflow issues. It has to be verified with every development sprint.

Performance and Load-Test

Input Output
Performance KPIs   Tough Day or equivalent test suite results, must be passed  
Use cases definitions   Validated test script against realistic and expected load  
Real content for testing   Customized Tough Day or equivalent test suite adapted to real content and result comparison to OOTB test run  
Full loaded test suite   Automated, or run manually on a regular basis  
  70% of the requests for pages respond in less than 100ms  
  No pages respond slower than 1 second.  
  Acceptance from business stakeholders  

Note

For more information about performance tests, see:

Rollout

Having both trained users and a high level of security is mandatory to be able to go live safely:

Training

Input Output
AEM Admin Training   Trained system administrators  
Standard author training   Trained authors/users  
If required: specific training material for application and/or site   End users trained  

Note

See Adobe AEM Training to find the trainings in the course catalog.

Penetration Test

Input Output
Security checklist   Security test report  
    Signed from system owner  

Go-Live

Input Output
List of security issues   Security issues fixed  
Security checklist   Security enabled  
Penetration test   Penetration test passed  
Fallback system   System and process available for switching back  
Fallback procedure tested   Fallback Procedures passed testing  
Go-live schedule   Adobe Support is informed about the go-live schedule  

Operations

You need to define roles (such as author, contributor, administrator) with specific permissions for your users. It is also mandatory to maintain and monitor your system as the project proceeds and to be able to backup and restore in case of emergency:

Permissions

Input Output
Permission concept (list of roles, groups)   Permissions meet security guidelines  

Note

  • List of roles (i.e. groups) with read/write access definitions for each. 
  • Privileges like replicate defined. 
  • 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, read User Administration and Security.

Maintenance and Monitoring

Input Output
Disk space monitoring   System monitoring enabled  
CPU monitoring   Threshold and interventation enabled  
Disk I/O monitoring   External system monitoring enabled  
Network bandwith monitoring    
DataStore garbage collection enabled and tested    
Repository optimization    
External system monitoring    
Request monitoring    

Note

See also Monitoring and Maintenance for more information.

Backup and Restoration

Input Output
Backup of author and publish instances   Recovery plan and procedures documented  
Restoration tested and documented    
Cluster: steps for cloning were tested and are documented    

Note

In an emergency situation, a full rollback/restoration must be available to secure the production use of AEM.

Any questions?

Have a question about this or any other AEM topic? Ask our Community.
Learn more about AEM topics on our help hub.
Was this helpful?

By submitting your feedback, you accept the Adobe Terms of Use.

Thank you for submitting your feedback.