Customer Centric Software Project Management Tomas Nystrm - - PowerPoint PPT Presentation

Customer Centric Software Project Management

Tomas Nyström 21.4.2005

Accenture – Company Background

• Global

– Over 100 000 people

• In Finland we are 650+

– Accenture

• Traditional consulting

– Accenture Services

• Outsourcing / Application Management

– Accenture Technology Solutions

• Hard core technology knowledge
• Mobile lab
• During the last five years Accenture has

delivered almost 18.000 projects to over 4000 clients.

• Every fourth hour (on average) an Accenture

implemented IT system is taken into productive use.

Tomas Nyström

• Started studies in HUT in 1991

– Worked part time during studies with programming – Major in “computer-systems”, minor in “industrial economy” – Master’s Thesis for Nokia about Software Methodology

• Graduated in 1997 and joined Accenture, now with a 7½ year work

history consisting of: – Custom & package delivery experience – Consulting & outsourcing delivery experience – Offshore & onshore delivery experience – Pre-sales & sales & delivery & maintenance experience – Developer, Team Lead, Architect, Project Manager, Program Manager experience – Currently Senior Manager in the Global Architecture and Core Technologies group (GACT) leading a Product Development Offshore engagement.

Sales Sales Execution Execution

Customer Interaction Overview

RFI RFP Req Design Build Test Accept Design Build Test Prop Deal

Entry point +/- to next entry point Customer interaction has two main phases: Deal Shaping ie the sales process and the Execution phase ie the actual project / program delivery phase.

Team Estimates Continuity Requirements Reporting SC Client People Client Effort Assumptions Process Model AT Distributed Work

Sales

“Sets the foundation for success”

Sales Entry Point

Sales Sales

Your previous customer relationship will determine your entry point. The better your relationships the larger the chance that you will win (as you have less exit points). Remember that IT sales is totally different from selling used cars.

RFI RFP Prop Deal

Entry point Exit Exit Exit

Note that government agencies always follow the same legislated bidding processes regardless of existing relationships.

Request For Information. A means to gather information from vendors about skills, references and interest. Request For Proposal. Documentation containing information to write proposal. Sent out to all potential

• vendors. Time to write proposal can be anything from weeks

to months. Proposal based on RFP and additional discussions / clarifications. Deal - basically meaning contract negotiations, usually only including one party.

Exit

Note that this overview just covers the formal sales process – deal shaping can include a number of other activities prior to the actual bidding and proposal process – and even during it.

Sales Team

The sales process is a small project that needs a project manager like any other

• project. The responsibility of the sales project manager is to ensure the delivery of a

quality proposal on time (and budget).

The purpose of the proposal is to create a compelling Value Proposition that consists of:

• Scope
• Requirements
• Estimate
• Pricing
• Resources
• Partners
• References
• Methodology
• Business case
• …

Depending on the project size the size of the team can be anything from a few people for a few days to a large team with almost no upper limit. For bigger Software Projects that span multiple years and are of some complexity a team of ~5 people for a few months is not unusual. Typically point-experts are brought in to participate already in the proposal phase to ensure high quality and accuracy of estimates and proposed solution.

Estimation

Execution effort estimation occurs in multiple places. Key is to understand what can be promised when and what the promise is founded on.

Sales Sales Execution Execution

RFI RFP Req Design Build Test Accept Design Build Test Prop Deal

Entry point

Phases with estimation.

(Sales) (Sales)

Estimation and Deal Type (Simplified)

Fixed Price. Price or effort needs to be committed in

• advance. All time above

agreed price usually at

• wn cost.

Sales Sales Execution Execution

RFI RFP Req Design Build Test Accept Design Build Test Prop Deal

Entry point

Sales Sales Execution Execution

RFI RFP Req Design Build Test Accept Design Build Test Prop Deal

Entry point

Time & Material. Price or effort needs to be committed in advance. All time above agreed price usually at own cost.

Sales Sales Req Req

RFI RFP Req Prop Deal

Entry point

Prop Deal

Execution Execution

Accept Design Build Test

Requirements Definition. If requirements are unclear and a fixed-price or a better fork is wanted a short requirements definition phase is usually called for,

Deal type plays a key role in sales process. Fixed price is usually more heavier as it indicates cost control while time & material indicates value thinking and thus emphasis of overall business case.

Requirements

Requirements are key to understanding effort. Requirements are extremely difficult to comprehensively document (ambiguity & completeness & internal consistency). Requirements can be categorized into two groups; functional and non-functional.

Functional Requirements document the functionality of the system. Typically functional requirements contain the following type of documents:

• Use Cases
• Business rules
• Screen shots
• High level domain model
• Interfaces
• Batch runs
• Reports
• …

Non-functional Requirements document everything else. Typically non-functional requirements cover areas that the end-user or interface does not care about from a functional point of view:

• Technology (J2EE / .NET / C++, Application Server, DB, OS, middleware, …)
• Use of existing frameworks (Company internal, 3rd party or open-source)
• Performance (response times, memory consumption, CPU usage, scalability, frequencies etc)
• Integration technology (real-time, batch, …)
• Localisation (Languages, currencies, time-zones, calendars etc)
• End-user requirements (PC requirements, browser requirements, mobility devices)
• Security (authentication, authorization, auditing, …)
• Administration
• Operational requirements (backups, system administration, user mgmt etc)
• Tools (IDE, requirements mgmt, issue tracking etc)
• …

Without proper requirements estimation can only at best be benchmarking.

Estimation – How-to

Once the requirements are clear the actual estimation is usually not that a difficult

• task. The only real magic involved are the estimating factors that come out of
• experience. Estimation can be done top-down or bottom-up.

Top-down estimation means a high granularity breakdown based on quick requirement analysis. Bottom-up estimation means a detail breakdown based on detailed requirement analysis.

Example Example

Doing this usually requires customer interaction as a result of increased understanding of the solution. Never estimate anything you have no previous experience from!

Assumptions

Once the estimation is done a number of assumptions have (hopefully) been

• identified. These assumptions are critical to document as part of the proposal to

ensure no holes exists.

Assumptions = Your understanding of the requirements Assumptions = Scope clarifications / scope demarcation Examples of detail assumptions on functionality:

• Missing Use Cases (logical gaps)
• Unclear Use Cases (missing steps, screens, interface definitions etc).
• …

Example of detail assumptions on non-functionality:

• Interface technologies
• Performance
• …

Example of detail assumptions on responsibility demarcation:

• Conversions
• Interface technology
• Hardware
• Software licenses
• Training
• End-user documentation
• Client performed work / client responsibility
• …

Client Effort

Of the Assumptions the most important one is client effort and responsibility - if not clearly stated in the RFP.

Execution Execution

Req Design Build Test Accept Project Management Steering Committee Production Preparation (Training, Conversion, HW, Production-planning, …) Support Processes (Change Control, Issue Management, …) Business Knowledge Support / Project Infrastructure

Committing

Once the assumptions and estimates are in place you need to decide on committing

• r not.

Is the project / program such that it makes sense for you to participate – do you believe in it?

• Is the scope “right”?
• Are the goals realistic?
• Is the client internally aligned?
• …

Do you believe that your estimate is solid?

• Can you deliver with the assumptions?
• ..

Do you have the skills?

• Can you bring together a team to do the work?
• ..

Do you have a competitive proposal?

• What makes your proposal unique?
• ..

…

Sales Sales Execution Execution

Continuity

RFI RFP Req Design Build Test Accept Design Build Test Prop Deal

Entry point How do you ensure continuity from sales mode to execution mode?

Relationships, ”promises”, skills, attitude, …

Execution

“Making sure you deliver what was sold”

Is the Customer Always Right? Yes and No The customer has the right to decide but is not always right.

“Process Model”

The methodology is extremely important and is usually one of the competitive

• advantages. The process model is part of the methodology and has a varying role

from project to project. Sometimes the client enforces it - sometimes it is left open.

”Delivery Methods” Library

Accenture Delivery Processes Accenture Delivery Tools Accenture Delivery Architectures Accenture Delivery Metrics Accenture Delivery Methods

Deep inside

What does the Customer do in the Execution Phase?

Hopefully what was agreed as part of the assumptions in the contract.

Execution Execution

Req Design Build Test Accept Project Management Steering Committee Production Preparation (Training, Conversion, HW, Production-planning, …) Support Processes (Change Control, Issue Management, …) Business Knowledge Support / Project Infrastructure

Leading Customer People

If you have a number of customer people participating in the execution phase responsible for parts of delivery you have both an upside and challenge.

Upsides:

• Buy-in
• Knowledge transfer in
• Knowledge transfer out
• Teaming with the client
• …

Potential challenges:

• Scope creep
• Performance problems
• How to be tough and get things

done?

• ..

Usually the more client people are involved in the execution phase the higher the likely hood of success – assuming not too much delivery responsibility is burdened on the client. Client management Client developers Client team lead Client project manager Communication Lines

Reporting and Transparency

Reporting is a standard part of any project / program. Reporting should be used to build client relationship. Reporting is also one way to ensure transparency – key to a trusted relationship.

Weekly Project Status Report Monthly Steering Committee Weekly Team Lead Reports Project internal reporting Available to the client

Scope Schedule Budget

Level of visibility? Reporting should focus around:

Steering Committee

Steering committees exist to support project management. In SC the project management gets approval for key decisions and in certain situations the SC will independently of project management dictate next steps and direction.

Use the steering committee to:

• Ensure continued buy-in / re-sell the project
• Get face time with senior client people
• Get support in key decision
• Ask resolution in issues
• Go through key risks and the mitigation plans

Remember to:

• Keep it simple – key senior client people might

have quite a few project to sit through each week

• Remind of the goals of the project
• Take notes and maintain an action list
• Have a balanced view – do not be too optimistic or

pessimistic

Issue #1:… 1. Situation 2. Complication 3. Solution

Weekly Project Status Report (Word) Monthly Steering Committee (PowerPoint) Project / Program Manager view of the situation (focus on risks and issues) Highly condensed (1-2 slides) (3-5 slides)

• Summary
• Budget
• Overview (graphical)
• Overview (text)
• Issues
• Risks

Acceptance Testing

Acceptance testing is usually the first time a large number of client people get hands-on experience with the solution, even if most of them are not buyers the

• pinion they form will impact your client relationship.

Req Design Build Test Accept Design Build Test

Key risk to overcome is the (usually) quite late stage in the project when Acceptance Testing occurs. Use whatever means to mitigate this risk: Lessen the “new” factor:

• training,
• communication
• change management
• Try move / start AT earlier
• “process model”

Scope Management

During the project a rigorous issue / defect / change request management process is

• required. All projects will generate scope creep unless managed well. A tool and well

defined process to manage scope is needed to remove any “feelings” from the client communication.

Issues Defects Change Requests Approved Rejected Postponed

Tool & Process

Scope Schedule Budget

Impact analysis Changes Use project estimation tool to estimate changes in scope

Distributed Work

Distributed work creates extra challenges in client communication and transparency, especially if done in different geographies and time-zones.

Onsite team Offshore team Client

Official Official In-official Key themes:

• Distribution of work
• Communication
• Tools
• Processes

Client Presence

Thank You for Your Attention! Any questions? tomas.nystrom@accenture.com