Managing Customer Specific Projects Tomas Nyström

Transcription

1 Managing Customer Specific Projects Tomas Nyström

2 Chaos is Back 28% of IT projects succeed 51% of IT projects are "challenged ; seriously late, over budget and lacking expected features 18% of IT projects are cancelled before completion ComputerWorld 8 November Recent statistics from the Standish Group.

3 The Project Defined Scope Schedule Budget

4 The Project Defined Scope Risk Level Defines Schedule Budget Quality Target

5 Project Manager Work Profile What does the Project Manager Really do? Work effort management and taking action, 85% Resource management, 83% Communication, 80% Getting customer commitment, 74% Milestone planning, 70% Change management, 60% Project plan management, 57% Ensuring leadership commitment, 45% Conflict management, 42% Vendor management, 38% Bob Hughes, Mike Cotterell, Software Project Management, s. 8

6 Project Management Project Management Leadership Management Administration Setting the direction Aligning the people Motivating the people Providing an example Giving feedback Project planning then Ensure and control the execution of the plan Communication Conflict mgmt Scope management Risk management Fishing Re-sell the project Get management buy in Time reporting Billing Resource management Budget tracking Status reporting Issue management

7 Different Levels of Management

8 The Project Plan? Project overview: background and relation to other projects Project contents: goals, scope, tasks, deliverables, work estimates, approaches, timetable and budget Project structure; organization, resources, roles, teams, modes of co-operation, budget split-up, interfaces to other systems and projects Project management mechanisms; reporting, meetings, metrics and project status tracking mechanisms, acceptance process Project risk mapping Assumptions that are used in the project plan

9 Level of detail Work Breakdown Structure Project phases, activities, task packages and tasks Work manageability Split work into tasks that are less than one week in duration / effort (5 FTE) 50 %:n compeltion is easier to identify from four 5 FTE tasks than from one 20 FTE task Link tasks to deliverables One task equals one deliverable (design document, source code, test case, configuration file,...) Through the deliverables the actual completion level is easier to understand

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

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

13 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

14 Definition - Quality Q: What s the definition of Quality? A: Zero Defects B: Degree of Excellence C: Conformance to Customer Requirements D: Doing It Right The First Time

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

16 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

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

18 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

19 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

20 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)

21 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

22 What is a Successful Project? Customer success (quality) Expected deliverables Time / budget Internal success People development Time / budget Project margin The customer recommends you

23 Thank You for Your Attention! Any questions?