We cover the following topics - Business case, Vision statement, Project Charter, Product

Roadmap, types of agile contracts, process tailoring, and who Stakeholders are and why

they are important for the success of a project.

Now let us hear from the coach

Thanks Dave, let me take it from here.

Business Case

A Business Case helps to decide whether a project is worth the investment for the business

It is used for decision making by managers and executives

It contains the business need and cost-benefit analysis and

Includes inputs from various stakeholders A project can come about due to many reasons,

and typically projects help realize the strategic objectives of an organization. Some of the

reasons for initiating a project are

Market demand - Such as a demand for cheaper gas;

Organizational need - For automating payroll; Customer request - For an online business

presence; Technological advance - Where customers need

smart phones; Legal requirement - For example, to comply

with Sarbanes Oxley act; Social needs - Such as improving quality of

living in a developing country.

Vision

A VISION statement helps explain the purpose or the WHY of the project. This helps everyone

on the project team to focus their effort.

Explaining the vision for a project can be done using various means, such as an elevator

statement or design-the-box activity

An Elevator statement concisely describes the vision of a project and a sample format

has been provided as shown.

Here is one vision statement for the case study example:

For Who

The is an

That ,

Unlike Our product

about patients medical records>.

In another method, called as the Design-the-box, team members work together and describe succinctly

about the product on the face of a box.

It is essential that everyone on the team knows what it is they are working on and WHY!

Without this single focus, team energies cannot be channeled. Hence the very first step for

the product owner is to work on the vision with the help of the team.

Agile Contracting

Agile Contracts can be tricky, since the complete scope of work may not be clear upfront. Therefore,

variations in the standard types of contracts exist. As a customer you will want to reduce

your risk and, hence may opt for a fixed price contract, while the vendor would be more in

favor of a Time and Material Contract. So, be aware that many factors dictate the type

of contract in a given situation.

Broadly speaking, here are the different types of contracts.

Number 1 : Fixed price contract Number 2 : Time and material contract

# 3: Time and material with a cap # 4: Fixed price per story point

# 5: Fixed price per release

Now let us get into each of the in detail:

Number 1: Fixed price contract Here the scope and time are fixed and hence

not agile friendly Any new changes may have to go through change

control or, if the contract permits, be accommodated by removing stories of equal story points

In this contract, it is suggested that customer pay at the end of every iteration

#2 : Time and Material [T&M] contract – this is best suited for agile projects, because

the customer can terminate the project anytime. In this type of contract, costs of material

or labor are known upfront while the only variable is the time required for the project

#3: Time and Material with a cap, which limits the customers exposure on the higher side

#4: Fixed price per story point, where the contract is paid based on the story points,

and #5: Fixed price per release, where the contract

is fixed price for a particular release

Scrum uses two clauses - Money for Nothing and Change for Free - that we will discuss

in detail next.

Agile Contracting

Here we discuss two clauses that are popular in Scrum contracts and they are - Money for

Nothing and Change for Free.

MONEY FOR NOTHING is a contract clause that under certain conditions allows the customer

to terminate a project by paying the vendor a small termination fee.

The customer may wish to terminate the project for various reasons, such as - changing business

conditions, project work having realized sufficient business value or for any other reasons.

This gives flexibility to the customer since they save money by NOT spending on features

they NO longer need.

Another contract clause is the CHANGE FOR FREE. Again, under certain conditions, the

customer and vendor can exchange equal amounts of work for no additional cost.

This means that any new work can only be accepted if an equal amount of existing work is removed.

Due to better understanding of their needs or due to changing business and market conditions,

customers may want to replace work they had already committed to. This mechanism protects

both the customer and the vendor and the customer gets to introduce new work for free.

These give us an idea of how agile contracts can be structured to benefit both the customer

and the vendor.

Project Charter

After the contract is signed, the customer issues a project charter, which formally authorizes

the project into existence. The project charter can be a simple document and should contain

high level details of the purpose and business objectives of the project.

This is typically developed by the sponsor, that is, the one who funds the project.

At a bare minimum, it should contain the Vision (to answer the “Why” of the project),

the Mission (to state the “How”), and the success criteria (to measure if the project’s

goal is achieved).

Traditional project success criteria generally focus on satisfying Scope, Schedule and Cost

parameters. This in itself may not provide true business value, which actually should

be the project success criteria. This is what Agile follows

Let us listen in on Bob, the Manager, authorizing the project.

I am authorizing this project by issuing a Project Charter.

Thanks Bob!

Dave, remember that our goal is to create value to the customer.

Product Roadmap

A PRODUCT ROADMAP shows the overall plan of what features go in which release over a time

period. The product owner with the assistance of the team is responsible to create the overall

plan laying out in broad details as to what will be accomplished in each time period.

As business conditions change, the product roadmap should be updated to keep it current

with the overall project understanding.

Take a look at the example here. The product roadmap lays out three releases, one in each

quarter. At a high level it presents what is planned to be achieved.

Again, remember this is just a plan, and subject to change!

Stakeholders

Stakeholders are people and organizations Who are involved in the project, or

Who are impacted by the project, either positively or negatively, as a result of project execution

or completion

An example of a positive stakeholder would be the customer, since they benefit from the

project. A negative stakeholder could be an employee whose job would be replaced by automation.

It is critical that stakeholders are identified early and as often as required.

Here is an example list of stakeholders, which includes:

Agile Manager or Coach Senior Manager

Developers Testers

Sponsors Users

Vendors and others

The stakeholder diagram is just one representation; it most likely will be different in your own

case.

Managing stakeholders is one of the keys in Agile projects, and we will discuss this in

greater detail next

Stakeholder Management

STAKEHOLDER MANAGEMENT is about understanding stakeholder interests, involvement and potential

impact on project success.

This calls for an intensive communication and dialogue with all concerned

As someone managing an agile project, you must engage with both primary and secondary

stakeholders and constantly monitor and redesign processes to better serve everyone

The typical skills required in stakeholder management include interpersonal and management

skills

Examples of Interpersonal skills include – Resolving conflict

Building trust Active listening

Overcoming resistance to change

Examples of Management skills include – Presentation skills

Negotiating Writing skills, and

Public speaking

Now, let us focus on how we manage stakeholder expectations

Manage Stakeholder Expectations

Stakeholder Expectations should be managed effectively, since each one's needs could

differ. If you are in the role of managing a project, then it is your responsibility

to find a solution that satisfies multiple stakeholders.

Let’s take an example:

You are an agile manager working at EvantTech. Let us see what some of the stakeholder expectations

look like: The client wants to get as much of the scope

into the project for the given budget Your manager expects you to complete the project

as fast as possible, to bring in new revenue Your vendor is desperate to work with you

on a large piece of the pie, so as to make more profit

Your project team is excited to try out the new technology on this very project

The functional manager is requesting that you release (right away) one of the key team

member loaned to you The PMO is insisting that you follow the company

processes and standards The Quality department has issued you a Non-Conformance

report

And we can go on. Now it becomes apparently clear how you are

expected to use multiple skills in managing the stakeholders to ensure a successful project.

Stakeholder Classification

It is important that Stakeholders are managed appropriately based on their interest in the

project and the power they have. Take a look at the graph here which plots “power”

vs “interest”; “Power” is the authority they can exert over the project, while “interest”

implies concern

The most important quadrant of stakeholders that needs to be managed closely is those

that have high interest and also high authority.

The next most important quadrant of stakeholders that needs to be kept satisfied is those that

have low interest but have high authority or power.

The stakeholders in quadrant 3, that is, those who have high interest but low power, needs

to be kept informed.

Finally, put in a minimum effort to monitor stakeholders low on interest and low on authority.

Can you answer these questions, please?

A high level plan which shows the grouping of features to be delivered at different times

is a:

(A) Project Plan (B) Product Roadmap

(C) Vision Document (D) Project Charter

What is your choice?

Project Plan - This only offers help on how to accomplish the project goals