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.
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. Sales Execution Sales Execution Continuity Reporting Team Client Effort Client People Requirements SC RFI Estimates Process Model Distributed Work AT Assumptions RFP Req Design Build Test Prop Accept Deal Design Build Test Entry point +/- to next entry point
Sales “Sets the foundation for success”
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. Sales Sales Request For Information . A means to gather information RFI from vendors about skills, references and interest. Request For Proposal . Documentation containing RFP information to write proposal. Sent out to all potential vendors. Time to write proposal can be anything from weeks to months. Exit Proposal based on RFP and additional discussions / Prop clarifications. Exit Deal - basically meaning contract negotiations, usually only Deal including one party. 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 Entry point Exit 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 Execution Sales Execution RFI RFP Req Design Build Test Prop Accept Deal Design Build Test Entry point Phases with estimation.
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 Sales Sales Execution Execution RFI needs to be committed in advance. All time above RFP agreed price usually at Req Design Build Test own cost. Prop Accept Deal Design Build Test Entry point Time & Material . Price or Sales Sales Execution Execution effort needs to be RFI committed in advance. All RFP time above agreed price Req Design Build Test usually at own cost. Prop Accept Deal Design Build Test Entry point Requirements Definition . Sales Sales Req Req (Sales) (Sales) Execution Execution If requirements are unclear RFI and a fixed-price or a better fork is wanted a Prop RFP short requirements Deal Prop definition phase is usually called for, Deal Req Design Build Test Accept Entry point
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 . 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!
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 Steering Committee Support / Project Infrastructure Business Knowledge Project Management Req Design Build Test Accept Production Preparation (Training, Conversion, HW, Production-planning, …) Support Processes (Change Control, Issue Management, …)
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? • .. …
Continuity How do you ensure continuity from sales mode to execution mode? Relationships, ”promises”, skills, attitude, … Sales Execution Sales Execution RFI RFP Req Design Build Test Prop Accept Deal Design Build Test Entry point
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.
Recommend
More recommend
