Managing a project to implement Adobe Experience Manager (AEM) requires planning and understanding to ensure you are aware of the issues and (related) decisions that you need to make (both before and while implementing your project).

Status by Role

Phases and Milestones

Each phase contains its own milestones. For each persona (or role), the relevant milestones are listed, together with the documents that are required to produce the defined deliverables.

Note:

There is not a direct 1:1 relationship between the individual required documents and deliverables.

Preparation

Preparation of your project forms the basis of the entire project. You need to define key requirements together with clear goals and expectations for the:

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.

How you prepare, plan and run your project and implement your solution will be affected by the restrictions you are operating under e.g. fixed budget, fixed timeline, quantity of content, quality required.

As always, adjusting any of the factors will impact the others. For example reducing the time, but requiring the same level of quality will probably increase the price while reducing the quantity of content you can cater for. Budget is often a key factor so such relationships cannot be forgotten.

The Four Factors:

Milestones

Validation

In this phase you need to validate and confirm the goals for the project; for example:

What do you want to achieve/provide?

Who will benefit?

What is the scope?

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

How will you define success?

How will 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 will be involved?

How will you measure progress?

How often will you review progress during the life of the project?

Budget

Before you start any project you need a reliable, realistic estimation of what it will cost 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 may be subject to.

Consider contingency and review processes should a review, or refinement, of the budget is required at a later stage.

Remember that costs come in many forms; purchases, use of resources and fees amongst others.

Planning

Planning your project consolidates the preparation. Here you need to start converting the goals and expectations into a well-defined roadmap consisting of concrete tasks, bound by clear communication, with stringent reviews to measure progress.

Milestones

Handover

A clean handover ensures that the appropriate persona/groups are aware of their responsibilites 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 vunerabilities 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. You need to 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 Preparation

Planning the development is key to ensure that your project is built on a solid design by a team that has the required knowledge.

Milestones

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, etc.

Multi site and multi language structures (MSM, Translation, etc.)

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 (amongst other information):

Operations Planning and Operations

On a similar basis the operations must be properly planned to ensure you have the environments that you require - for all stages of the project life cycle. You also need the appropriate processes for maintaining them.

Milestones

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 (i.e. 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

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.

This process will have to be continued during normal use of AEM, but these initial stages are the most crucial.

Rollout

Rollout of your new application needs careful planning to ensure a smooth Go Live. This includes confirming a high level of security, training all prospective users and making multiple dry-runs to confirm that all issues have been dealt with.

Go Live

You want your Go Live to be as smooth as possible. Again the final steps need planning for clean execution.

Milestones

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.

Persona

The checklists are designed by persona. These are the roles with significant involved in the project life cycle.

There are also some other persona that are involved in specific tasks.

Project Sponsor

The project sponsor is:

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.

Project Manager

The project manager is:

Responsible for the overall delivery of the project based on the requirements (e.g. scope, KPIs, success criteria and definition) provided by the project sponsor.

Responsible for defining the budget and resourcing the project based on that budget.

The main point of communication for all persona involved in the project.

Architect

The solution architect:

Is responsible for the high-level design of the solution and system.

Helps define the implementation strategy for AEM. For example, whether to implement a clustered installation, or a cold standby, or when a content delivery network (CDN) is needed.

Also define the AEM solution architecture based on the client requirements. This can include the concept for user roles (with related rights), the relationship between templates and components, or when to use multi site management.

Business Analyst

The business analyst:

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 analyse the requirements. They match these against:

The definition of success.

The criteria for success.

KPIs (both business and performance based).

Development Lead

The development lead:

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.

Quality Lead

The quality lead:

Is responsible for the quality of the delivery; ensuring that it meets the criteria for success and any KPIs defined by the client.

Defines the quality metrics, aligns with all stakeholders, draws up the testing plans and ensures that they are executed.

Creates and delivers reports to project stakeholders.

System Engineer

The system engineer:

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.

Security Lead

The security lead:

Is responsible for the overall security concept of the solution, ensuring that it is aligned with any requirements and policies from the client.

Delivers a security concept, security operations and recommendations for any hardware based security concepts; such as zones and firewalls.

Other Persona

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; e.g. 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 will use the system to create and maintain your website content.

Required Documents and Deliverables

The checklists cover the Required Documents and Deliverables for each milestone.

There is no 1:1 relationship between these; for example, a group of required documents can result in a single deliverable.

A deliverable from one persona can be a required document for another persona during the same milestone.

Required Documents

The Required Documents are needed by the appropriate persona when producing their deliverables.

For each Required Document the persona should indicate:

Y/N: whether it has been received.

1-3: an indication of the quality of the received document.

Deliverables

For each milestone the appropriate persona are responsible for delivering specific documents and therefore realizing their responsibilities for a specific milestone.

For each Deliverable the persona must indicate:

Y/N: whether it has been completed.

Deliverables are often used as Required Documents for either the current or a later milestone.

Related Best Practices

For best practices on deploying, administering, developing, or authoring, see the following: