Customer Centric Software Project Management Tomas Nyström

Transcription

1 Customer Centric Software Project Management Tomas Nyström

2 Accenture Company Background Global Over 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 projects to over 4000 clients. Every fourth hour (on average) an Accenture implemented IT system is taken into productive use.

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

4 Customer Interaction Overview Customer interaction has two main phases: Deal Shaping ie the sales process and the Execution phase ie the actual project / program delivery phase. RFI Sales RFP Team Estimates Assumptions Continuity Requirements Client Effort Process Model Execution Client People Distributed Work Reporting SC AT Prop Req Design Build Test Accept Entry point Deal Design Build Test +/- to next entry point

5 Sales Sets the foundation for success

6 Sales Sales Entry Point 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 Exit Prop Exit Deal 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. Entry point Exit Exit Note that government agencies always follow the same legislated bidding processes regardless of existing relationships. 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.

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

8 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 Execution RFI RFP Prop Req Design Build Test Accept Entry point Deal Design Build Test Phases with estimation.

9 Estimation and Deal Type (Simplified) 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. Fixed Price. Price or effort needs to be committed in advance. All time above agreed price usually at own cost. RFI Sales RFP Prop Execution Req Design Build Test Accept Deal Design Build Test Entry point Time & Material. Price or effort needs to be committed in advance. All time above agreed price usually at own cost. RFI Sales RFP Prop Execution Req Design Build Test Accept Deal 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, Entry point RFI Sales RFP Prop Deal Req Req (Sales) Prop Deal Execution Design Build Test Accept Entry point

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

11 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. Example Bottom-up estimation means a detail breakdown based on detailed requirement analysis. 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!

12 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

13 Client Effort Of the Assumptions the most important one is client effort and responsibility - if not clearly stated in the RFP. Execution Business Knowledge Steering Committee Project Management Req Design Build Test Accept Production Preparation (Training, Conversion, HW, Production-planning, ) Support Processes (Change Control, Issue Management, ) Support / Project Infrastructure

14 Committing Once the assumptions and estimates are in place you need to decide on committing or 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?..

15 Continuity How do you ensure continuity from sales mode to execution mode? Relationships, promises, skills, attitude, Sales Execution RFI RFP Prop Req Design Build Test Accept Entry point Deal Design Build Test

16 Execution Making sure you deliver what was sold

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

18 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. Accenture Delivery Methods Accenture Delivery Processes Accenture Delivery Tools Accenture Delivery Architectures Accenture Delivery Metrics Deep inside Delivery Methods Library

19 What does the Customer do in the Execution Phase? Hopefully what was agreed as part of the assumptions in the contract. Execution Business Knowledge Steering Committee Project Management Req Design Build Test Accept Production Preparation (Training, Conversion, HW, Production-planning, ) Support Processes (Change Control, Issue Management, ) Support / Project Infrastructure

20 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. Communication Lines Client management Client project manager Client team lead Client developers

21 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. Project internal reporting Weekly Team Lead Reports Weekly Project Status Report Monthly Steering Committee Available to the client Reporting should focus around: Level of visibility? Scope Schedule Budget

22 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 Summary Budget Overview (graphical) Overview (text) Issues Risks Weekly Project Status Report (Word) Monthly Highly condensed (1-2 slides) Steering Committee (PowerPoint) (3-5 slides) Project / Program Manager view of the situation (focus on risks and issues)

23 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 opinion they form will impact your client relationship. Key risk to overcome is the (usually) quite late stage in the project when Acceptance Testing occurs. Req Design Build Test Design Build Test Accept Use whatever means to mitigate this risk: Lessen the new factor: training, communication change management Try move / start AT earlier process model

24 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. Scope Use project estimation tool to estimate changes in scope Schedule Budget Changes Impact analysis Issues Defects Change Requests Tool & Process Approved Rejected Postponed

25 Distributed Work Distributed work creates extra challenges in client communication and transparency, especially if done in different geographies and time-zones. Client Official In-official Onsite team Official Offshore team Client Presence Key themes: Distribution of work Communication Tools Processes

26 Thank You for Your Attention! Any questions?