다음을 통해 공유

Envision: Inside the track

  • 아티클

This post presents a description of the envision track, adding detail to the different deliveries that all the teams should advocate. Many graphics have been presented on different websites with a simple graphic called “Envision”, but the question is, what is going on inside?

The following matrix can help to understand the different responsibilities that each advocacy group should attend during the envision stage.

Product Management

(define)

· Overall goals

· Identify customer requirements

· Vision / scope document (Key)

· Customer acceptance criteria

Programme Management

(deliver)

· Readiness analysis

· Project structure (key)

· Constrain identification

· Team organized (key)

Architecture

(design)

· Design goals

· Feasibility analysis

Development

(build)

· Prototypes

· Development and technology options

User Experience

(feedback)

· User performance needs and implications

· User acceptance criteria

Test

(probe)

· Testing approach

· Test acceptance criteria

Release / Operations

(Deploy)

· Deployment implications

· Operations management and supportability

(PM) Overall goals: Is important to define at this stage which is the main goal of the project / iteration, what we want to achieve with this work. It is recommendable that the items are SMART (Specific, Measurable, Achievable and Realistic)

(PM) Identify customer requirements: The product management should interact with the stakeholders; one of them is the customer (business sponsor). It is important to understand and identify what the customer needs in order to drive the goals of the project. This is the first stage of the continual involvement along the project, matching one of the principles of MSF.

(PM) Vision / Scope: This is the main deliverable of the envision phase. This key document should be approved and shared across the team before proceeding to the next track. The team and the customer should be included on the approval process.

(PM) Customer acceptance criteria: At this stage, we have identified what the customer needs, our goals and a shared vision is in place. This leads the product management to get the customer acceptance criteria. These items should be also SMART, as they will represent the level of success of the project.

(PgM) Readiness analysis: How well the team is prepared? Do we have all the necessary processes in place in order to deliver the solution? What is missing from the available resources? These are some of the questions included on the readiness analysis.

(PgM) Project structure: The project structure is another key delivery at this stage; it reflects the roles with needed skills and the abilities as identified by the readiness efforts. It reflects feature and function teams involved along the project. This will be the initial document used to plan the strategies to deliver the solution.

(PgM) Constrains identification: The list of constrains for the project should be well known to the programme management group, as these are the items that will constrain the project delivery. The product management has defined what they want, now the programme management needs to check the resources available, the budget, the timeframes, and the skills that the team has. At this stage the programme management group will be able to negotiate which features the delivery will include. An important model to remember at this stage is:

No Change

Shouldn’t change

Flexible

Resources

X

Time

X

Features

X

(PgM) Team organized: The team should be ready on this stage, all the resources identified and the roles per group defined, some of the roles that the group can have are:

Group

Role

Product Management

(PM) Lead Product Manager

(BA) Business Analyst

(MA) Marketing Analyst

Programme Management

(PgM) Program Manager

(PjM) Project Manager

(RM) Resource Manager

(PrA) Process Assurance

(POM) Project Operations Manager

(PQA) Project Quality Manager

Architecture

(SoA) Solution Architect

(TqA) Technical Architect

(IfA) Infrastructure Architect

Development

(LSDE) Lead software developer engineer

(SDE) Software developer engineer

Test

(FT) Functional tester

(ST) System tester

Customer Experience

(AcE) Accessibility engineer

(TSC) Technical Support Communications

(Train) Trainer

(UsE) Usability engineer

(UID) User interface designers

Release

(RM) Release Manager

(DIM) Delivery Infrastructure Manager

(OPS) Operations

(BdM) Build Manager

(Tool) Tools Admin

(SoA) Design Solution: A high level design of the solution is recommended at this stage. This represents a notional approach that describes how the different aspects of a solution will operate together.

(SoA) Feasibility analysis: The architecture and technology chosen has to be proven at this stage. It is not worth to continue with the project if the model is not tested against the project resources and skills. Gathering best practices and case studies is a good way to back up the architectural decision.

(SoA) Quality of Service: The first list of quality of service requirement should be in place; these are driven by the customer motivation and requirement. A sample can be performance, availability, scalability, and localisation.

(SDE) Prototypes: The envision track is an excellent opportunity to work with the architects and build a prototype of the solution; this will help to probe the feasibility of the solution and will help the developers to play with the technology required for the rest of the project. What is more, a prototype is an excellent opportunity to integrate some of the user interfaces designed by the customer experience group and validate them with the customer.

(SDE) Development and technology options: The lead developer should state which development standards will be applied on the project, organizing the source control and the branching technique is another good exercise. The environment should be ready to allow the project to run without glitches.

(UX) User performance needs and implications: Working with the user and the architects to define the quality of the service is very important at this stage. If the project will replace a running application is important to gather metrics about the current execution. We don’t want to deliver a solution that performs worst than the current implementation. The user is a key element and should not be confused with the customer.

(UX) User acceptance criteria: What will make the user happy? Collecting this type of information will help the project output. If the user is happy it will provide good feedback to the customer, increasing the chances of success. These items should be SMART.

(FT) Test Approach: As we don’t have anything to test yet is a good opportunity to organize the test team and define how the solution will be tested. Selecting the tools that are going to be necessary and what kind of automation will be necessary in order to reduce the testing times.

(FT) Test acceptance criteria: What will make the test a successful process? If we can quantify this it will help the test team to drive the test procedures. This is also a good metric to define the team goals.

(RM) Deployment implications: Working with the architects and the customer infrastructure to asset the deployment implications will help to tweak the final architecture. The deployment should be smooth and should not alter the production environment.

(RM) Operations management and supportability: The team should start to interact with the people that are going to operate the solution and the support team. It is considered good practice to incorporate these teams earlier in the project so they are aware of the functional properties of the solution.

Risk assessment

The risk assessment is built by all the different groups, as each different member will identify those affecting the individual goals. Managing risks is included in a different post as it needs some detail explanation. The risks are constantly revisited as the iterations help to keep all documents alive.

Comments