Project Checklists

Opomba:

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)

Opomba:

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

Opomba:

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.

Opomba:

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

• How to set target metrics?
• Project Kick-off

Opomba:

For AEM trainings and certifications, see:

• Adobe Training Catalog
• Adobe Certification

Opomba:

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

Opomba:

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)

Opomba:

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

Opomba:

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 

Opomba:

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

Opomba:

See the Adobe Support Portal.

Only trained developers are allowed read/write access.

Opomba:

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

Opomba:

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

Opomba:

To help you achieve this checklist, see:

• Tough Day test
• Best Practices for Quality Assurance
• Disk Benchmark (especially when Network filesystem will be used)

Opomba:

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)

Opomba:

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.)

Opomba:

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

Opomba:

For more information about performance tests, see:

• Performance Testing
• How to plan and run testing?
  
• Basic Performance Guidelines

Opomba:

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

Opomba:

• 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.

Opomba:

See also Monitoring and Maintenance for more information.

Opomba:

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